Summary: | Switching from Jullian to Gregorian did not happen the same date for all countries | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Stefanos Harhalakis <v13> |
Component: | kdecore | Assignee: | John Layt <jlayt> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | dhillonv10, jlayt |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Stefanos Harhalakis
2003-11-26 21:25:46 UTC
do you know of _any_ calendar that cares about that aspect? :) Subject: Re: Switching from Jullian to Gregorian did not happen the same date for all countries On Wednesday 26 November 2003 22:41, Stephan Kulow wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=69102 > > > > > ------- Additional Comments From coolo@kde.org 2003-11-26 21:41 ------- > do you know of _any_ calendar that cares about that aspect? :) ncal (It seems to be the cal from freebsd but it exists in some distributions including debian) <<V13>> I meant a GUI calendar, not a tool that is made to calc any academical date. This is a debate I been back and forth on a few times :-) On the one hand users should be able to see what the dates really were when they are doing historical related work. On the other hand any scientific or financial applications probably require consistency and accuracy. How do we know in advance what the user wants? Basically it is up to the app to decide and to implement the required model. I would like to implement this in KDE4 using a new KLocale variable and changing our Gregorian calendar class to pay attention to it, but a big issue arises with compatibility with QDate which only has a fixed conversion date. While in theory it shouldn't be an issue as KDE apps should always use the global KCalendarSystem for calculations, in reality some inconsistent programming inside an app mixing KCalendarSystem and QDate could easily lead to mistakes creeping in. And then you get the countries where different states and regions converted at different dates. And what about somewhere like China or Japan where the conversion date wasn't from Julian to Gregorian but from the local calendar system to Gregorian? My eventual conclusion was that this would be something for KDE5 :-) Assign to me to give it some more thought, and to revisit the kcd list debate we had last time this was raised, but I'm likely to close it. AFAIK, the ncal command displays a nice calendar and works fine for this year, and the one before it :) so this one's really not an issue. Therefore marking it invalid. Thanks. No it doesn't! Look at March :-) $ ncal -s GR 1924 1924 January February March April Mo 1 8 15 22 29 5 12 19 26 4 24 31 7 14 21 28 Tu 2 9 16 23 30 6 13 20 27 5 25 1 8 15 22 29 We 3 10 17 24 31 7 14 21 28 6 26 2 9 16 23 30 Th 4 11 18 25 1 8 15 22 29 7 27 3 10 17 24 Fr 5 12 19 26 2 9 16 23 1 8 28 4 11 18 25 Sa 6 13 20 27 3 10 17 24 2 9 29 5 12 19 26 Su 7 14 21 28 4 11 18 25 3 23 30 6 13 20 27 May June July August Mo 5 12 19 26 2 9 16 23 30 7 14 21 28 4 11 18 25 Tu 6 13 20 27 3 10 17 24 1 8 15 22 29 5 12 19 26 We 7 14 21 28 4 11 18 25 2 9 16 23 30 6 13 20 27 Th 1 8 15 22 29 5 12 19 26 3 10 17 24 31 7 14 21 28 Fr 2 9 16 23 30 6 13 20 27 4 11 18 25 1 8 15 22 29 Sa 3 10 17 24 31 7 14 21 28 5 12 19 26 2 9 16 23 30 Su 4 11 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 31 September October November December Mo 1 8 15 22 29 6 13 20 27 3 10 17 24 1 8 15 22 29 Tu 2 9 16 23 30 7 14 21 28 4 11 18 25 2 9 16 23 30 We 3 10 17 24 1 8 15 22 29 5 12 19 26 3 10 17 24 31 Th 4 11 18 25 2 9 16 23 30 6 13 20 27 4 11 18 25 Fr 5 12 19 26 3 10 17 24 31 7 14 21 28 5 12 19 26 Sa 6 13 20 27 4 11 18 25 1 8 15 22 29 6 13 20 27 Su 7 14 21 28 5 12 19 26 2 9 16 23 30 7 14 21 28 Of course this happens for other countries too. Look at September: $ ncal -s US 1752 1752 January February March April Mo 6 13 20 27 3 10 17 24 2 9 16 23 30 6 13 20 27 Tu 7 14 21 28 4 11 18 25 3 10 17 24 31 7 14 21 28 We 1 8 15 22 29 5 12 19 26 4 11 18 25 1 8 15 22 29 Th 2 9 16 23 30 6 13 20 27 5 12 19 26 2 9 16 23 30 Fr 3 10 17 24 31 7 14 21 28 6 13 20 27 3 10 17 24 Sa 4 11 18 25 1 8 15 22 29 7 14 21 28 4 11 18 25 Su 5 12 19 26 2 9 16 23 1 8 15 22 29 5 12 19 26 May June July August Mo 4 11 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 31 Tu 5 12 19 26 2 9 16 23 30 7 14 21 28 4 11 18 25 We 6 13 20 27 3 10 17 24 1 8 15 22 29 5 12 19 26 Th 7 14 21 28 4 11 18 25 2 9 16 23 30 6 13 20 27 Fr 1 8 15 22 29 5 12 19 26 3 10 17 24 31 7 14 21 28 Sa 2 9 16 23 30 6 13 20 27 4 11 18 25 1 8 15 22 29 Su 3 10 17 24 31 7 14 21 28 5 12 19 26 2 9 16 23 30 September October November December Mo 18 25 2 9 16 23 30 6 13 20 27 4 11 18 25 Tu 1 19 26 3 10 17 24 31 7 14 21 28 5 12 19 26 We 2 20 27 4 11 18 25 1 8 15 22 29 6 13 20 27 Th 14 21 28 5 12 19 26 2 9 16 23 30 7 14 21 28 Fr 15 22 29 6 13 20 27 3 10 17 24 1 8 15 22 29 Sa 16 23 30 7 14 21 28 4 11 18 25 2 9 16 23 30 Su 17 24 1 8 15 22 29 5 12 19 26 3 10 17 24 31 Don't close this as INVALID! I find WONTFIX acceptable (after all, this is a really minor perfectionism thing), but INVALID is... er... INVALID :-) @ Stefanos Harhalakis: You are right :) sorry about that. Wanted to click on that but my browser is did something weird. Since the problem persists in the time that isn't relevant to us at the moment, it doesn't make much sense to me to spend resources on this one. So closing it as won't fix :) |