Dates become 1 day earlier after leap day in non-millenial century years (2100, 1900, 1800, etc)

VERIFIED FIXED in 1.0b1

Status

VERIFIED FIXED
15 years ago
7 years ago

People

(Reporter: gekacheka, Unassigned)

Tracking

({dataloss})

unspecified
1.0b1
x86
Windows 2000
dataloss

Details

(Reporter)

Description

15 years ago
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)

Updated

15 years ago
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)

Comment 1

14 years ago
*** Bug 281623 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Depends on: 350
QA Contact: gurganbl → general

Comment 2

13 years ago
*** Bug 310724 has been marked as a duplicate of this bug. ***
Keywords: dataloss
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Flags: blocking0.3-
Events in 1900 and 2100 don't seem like an interesting use case for a 0.3 version, thus the blockin-.

Comment 5

12 years ago
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) 
(Reporter)

Updated

12 years ago
Duplicate of this bug: 356908
(Reporter)

Comment 7

12 years ago
Dates are mostly stored and formatted as calDateTime objects.  Datepicker uses Javascript Date.  Javascript Date incorrectly computes whether century 00 years are leap years, but formatter correctly calculates leap years, so dates become offset when set and formatted, leading to date display being a day off for each century.  Hopefully patch to bug 350 could fix Javascript Date.   (consider vote for bug 350).

Comment 8

11 years ago
I also noticed that entering 01-01-1940 in date picker below minimonth in lightning 2007082803 shows 31-12-1939

Comment 9

11 years ago
Bug from initial comment still occurs in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13pre) Gecko/20080218 Calendar/0.8pre
Duplicate of this bug: 485907

Comment 11

10 years ago
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.
(Reporter)

Comment 13

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Duplicate of this bug: 538952
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) 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.