User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316, 2004030911-cal Problem with leap year in non-millenial century years (2100, 1900, 1800, etc. but not 2000) For example if I use the event dialog to enter or select the date 1900-12-03 it is printed as 1900-12-02. (My os date format is yyyy-MM-dd). Every time I view the event in the event dialog, the event date is parsed again so the event date moves back one day each time. Reproducible: Always Steps to Reproduce: See above. Actual Results: 1900-12-03 becomes 1900-12-02 Expected Results: 1900-12-03 remains 1900-12-03 Spun off from bug 172908 Possibly related to bug 350 (though it is not clear whether bug 350 is a problem in non-century years before 1901 or after 2099, while this problem does not occur in non-century years). (Guess: inconsistent handling of century leap year between parser and formatter)
Summary: Dates become 1 day earlier after leap day in non-millenial century years (2100, 1900, 1800, etc) → Dates become 1 day earlier after leap day in non-millenial century years (2100, 1900, 1800, etc)
*** Bug 281623 has been marked as a duplicate of this bug. ***
*** Bug 310724 has been marked as a duplicate of this bug. ***
Reassigning all automatically assigned bugs from Mostafa to firstname.lastname@example.org Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Events in 1900 and 2100 don't seem like an interesting use case for a 0.3 version, thus the blockin-.
I don't know if this can be acccounted for as dataloss. In sunbird 0.3.1 it behaves better then in lightning. The exports of the calendars are similar. for Lightning: Something really strange is going on, jan 2-2101 view in calendar is correct, hover over is correct, opening the event gives jan 3-2101. Events on jan 1-2101 in view give a dec 31-2100 when hovering over and give a jan 2, 2101 when opening for edit. For sunbird: The view is correct, also the "hover over" shows the correct dates. When manually editing the startdate the end-date is not changed accordingly. When chosing the datepicker the end-date changes instantly to one day before. So, as for the next few decades this is pretty theoretical, we don't even have a nice UI to switch so many years, it seems like the fix should be pretty easy. Maybe the fix for bug 350 only made it to sunbird (and not to the datepicker) and not to lightning? hope this is enough info for you to work with related bugs: bug 356908 (similar behaviour as described in 356908 -before 1900- happens for dates after 28-02-2100) bug 350 (there's a fix dated 2005 which wasn't reviewed yet)
I also noticed that entering 01-01-1940 in date picker below minimonth in lightning 2007082803 shows 31-12-1939
Bug from initial comment still occurs in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20080218 Calendar/0.8pre
As bug 350 was fixed after almost 11 years, this should now work. I'll test tonight.
You'll need a selfmade 1.9.2 build for testing because the fix is only available in mozilla-central but not mozilla-1.9.1.
Appears fixed by bug 350 now that it is checked in on mozilla-1.9.1 (bug 350 comment 36). (Note: on w2k, dates with year on century 1700 and later work, but not 1600 and before (bug 391038), maybe because w2k does not support those dates. Wikipedia says the gregorian calendar started being used in Oct 1582 in Italy, Spain, Portugal, and Poland-Lithuania, and not until 1700 or later in many other countries.)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20100305 Calendar/1.0b2pre
Status: RESOLVED → VERIFIED
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.