1122571 - Date.toLocaleDateString() one day off for many dates, e.g. 28.03.1960 wrongly displayed as 27.03.1960 (involving daylight savings time?)

Status: RESOLVED DUPLICATE of bug 1346211

(Core :: JavaScript Engine, defect)

Description

[Martin]

Attachment: addressbook: shows diffrent birthdays in Contact Pane and Edit Contact Window

occours on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 Build: 20150109111741
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Thunderbird/36.0a2 Build: 20150107004010

Steps to reproduce:
Open Addressbook and create a Contact with birthday 28.03.1960.

What happens:
The Contact Pane shows the birthday 27.03.1960 (see attachment).

I expect that the birthday shown in Contact Pane is always identical to the one in the edit window.

Comment 1

[Martin]

Attachment: addressbook: shows diffrent birthdays in Contact Pane and Edit Contact Window

Comment 2

[Martin]

I made some more tests:

Edit Window | Contact Pane
28.03.1950  |  27.03.1950   <==
01.07.1950  |  01.07.1950
27.03.1960  |  27.03.1960
28.03.1960  |  27.03.1960   <==
29.03.1960  |  28.03.1960   <==
01.07.1960  |  30.06.1960   <==
01.07.1961  |  30.06.1961   <==
01.03.1970  |  01.03.1970
27.03.1970  |  27.03.1970
28.03.1970  |  28.03.1970
01.07.1970  |  30.06.1970   <==

Comment 3

[Magnus Melin [:mkmelin]]

Confirmed on linux trunk, apparently a bug in Date.toLocaleDateString();

e.g. 1960-03-28

var date = new Date(1960,2,28); alert(date + "\n" + date.toLocaleDateString());

 Mon Mar 28 1960 00:00:00 GMT+0300 (EET)
 1960-03-27

Comment 4

[Boris Zbarsky [:bzbarsky]]

The problem with midnights is which day the fall into depends on things like daylight savings time (in which year?) and whatnot....

Comment 5

[Magnus Melin [:mkmelin]]

Not sure that's the problem in this case.

Note that Date(1960,2,27) and Date(1960,2,28) shows the same result for Date.toLocaleDateString() - if it was a midnight problem I'd assume it to be consistently off by one day.

Comment 6

[Jens]

I also tested a few more years. Perhaps it may be useful for fault finding also still.
1942 & 1998 & 2015 are completely OK

The following periods are flawed to me.
 
1935 Monday 01.04. - Sunday 27.10. like 1940 & 1963 & 1968
1936 Monday 30.03. - Sunday 25.10. like 1964 & 1970
1937 Monday 29.03. - Sunday 31.10. like 1965
1938 Monday 28.03. - Sunday 30.10. like 1960 & 1966
1939 Monday 27.03. - Sunday 29.10. like 1967
1940 Monday 01.04. - Sunday 27.10. like 1935 & 1963 & 1968
1941 Monday 31.03. - Sunday 06.04.
1942 OK
1943 Tuesday 05.10. - Sunday 31.10.
1960 Monday 28.03. - Sunday 30.10. like 1938 & 1966
1963 Monday 01.04. - Sunday 27.10. like 1935
1964 Monday 30.03. - Sunday 25.10. like 1936 & 1970
1965 Monday 29.03. - Sunday 31.10. like 1937
1966 Monday 28.03. - Sunday 30.10. like 1938 & 1960
1967 Monday 27.03. - Sunday 29.10. like 1939
1968 Monday 01.04. - Sunday 27.10. like 1935 & 1940 & 1963 
1969 Monday 31.03. - Sunday 26.10.
1970 Monday 30.03. - Sunday 25.10. like 1936 & 1964
1980 Monday 31.03. - Sunday 06.04.
1980 Monday 29.09. - Sunday 26.10.
1981 Monday 28.09. - Sunday 25.10.
1982 Monday 27.09. - Sunday 31.10.
1983 Monday 26.09. - Sunday 30.10.
1984 Monday 01.10. - Sunday 8.10.
1985 Monday 30.09. - Sunday 27.10.
1986 Monday 29.09. - Sunday 26.10.
1998 OK
2015 OK

Comment 7

[Thomas D. (:thomas8)]

(In reply to Jens from comment #6)
> I also tested a few more years. Perhaps it may be useful for fault finding
> also still.
> 1942 & 1998 & 2015 are completely OK
> 
> The following periods are flawed to me.
>  
> 1935 Monday 01.04. - Sunday 27.10. like 1940 & 1963 & 1968
> 1936 Monday 30.03. - Sunday 25.10. like 1964 & 1970
> 1937 Monday 29.03. - Sunday 31.10. like 1965
> 1938 Monday 28.03. - Sunday 30.10. like 1960 & 1966
> 1939 Monday 27.03. - Sunday 29.10. like 1967
> 1940 Monday 01.04. - Sunday 27.10. like 1935 & 1963 & 1968
> 1941 Monday 31.03. - Sunday 06.04.
> 1942 OK
> 1943 Tuesday 05.10. - Sunday 31.10.
> 1960 Monday 28.03. - Sunday 30.10. like 1938 & 1966
> 1963 Monday 01.04. - Sunday 27.10. like 1935
> 1964 Monday 30.03. - Sunday 25.10. like 1936 & 1970
> 1965 Monday 29.03. - Sunday 31.10. like 1937
> 1966 Monday 28.03. - Sunday 30.10. like 1938 & 1960
> 1967 Monday 27.03. - Sunday 29.10. like 1939
> 1968 Monday 01.04. - Sunday 27.10. like 1935 & 1940 & 1963 
> 1969 Monday 31.03. - Sunday 26.10.
> 1970 Monday 30.03. - Sunday 25.10. like 1936 & 1964
> 1980 Monday 31.03. - Sunday 06.04.
> 1980 Monday 29.09. - Sunday 26.10.
> 1981 Monday 28.09. - Sunday 25.10.
> 1982 Monday 27.09. - Sunday 31.10.
> 1983 Monday 26.09. - Sunday 30.10.
> 1984 Monday 01.10. - Sunday 8.10.
> 1985 Monday 30.09. - Sunday 27.10.
> 1986 Monday 29.09. - Sunday 26.10.
> 1998 OK
> 2015 OK

Most of the flawed time spans look like daylight savings time (Sommerzeit) periods for countries like Germany from which Jens reported, where spring is in March and Summer will have ended in autumn.

Comment 8

[Thomas D. (:thomas8)]

We need birthday in the summary to avoid further duplicates.

Having javascript display wrong dates looks like major bug with potentially disastrous consequences on time-critical missions. Also datalossy.

Who are the module owners / Mozilla developers responsible for fixing this?

Comment 11

[Christian Hoffmann]

(In reply to Magnus Melin from comment #5)
> Not sure that's the problem in this case.
> 
> Note that Date(1960,2,27) and Date(1960,2,28) shows the same result for
> Date.toLocaleDateString() - if it was a midnight problem I'd assume it to be
> consistently off by one day.
I'm not sure what what exactly "midnight problem" means, but I'm pretty sure that this issue arises due to differences in timezone and DST handling which leads to dates wrapping to the previous day in some cases ("around midnight").

> new Date(1960,2,27).toLocaleString()
> "3/27/1960, 12:00:00 AM"
> new Date(1960,2,28).toLocaleString()
> "3/27/1960, 11:00:00 PM"

I think this "inconsistency" occurs because JavaScript Date objects are based on milliseconds since 1970, with each day having exactly 86,400,000 milliseconds [1], and because they use the currently valid DST algorithm for DST calculations [2], not the one effective for the given year.
In contrast to that, the .toLocale[Date|Time]String methods utilize the JavaScript Intl API [3], which may be backed by a full timezone database [4] and would as such include a lot more DST rules.

All in all, my current understanding is that the JavaScript engine behaves as specified. The fact that other implementations (such as Chrome's) behave the same also supports the argument that this is not an implementation bug. Also, there are other reports on this specification issue:
https://bugs.ecmascript.org/show_bug.cgi?id=342
https://mail.mozilla.org/pipermail/es5-discuss/2009-August/002964.html
http://stackoverflow.com/questions/17478086/chrome-timezone-option-to-date-tolocalestring

While I certainly agree that the behavior may be unexpected and is problematic in cases such as with the birthday handling in Thunderbird's addressbook, I think it's up to the API users to account for this problem, at least at the moment. I will post some suggestions in bug #1139167, which is about the Thunderbird-specific point of view.

So at this time, I would suggest to close this JavaScript engine bug as INVALID as Gecko behaves according to the spec, while keeping bug #1139167 open to work around this problem in Thunderbird (or: move this bug to the Thunderbird component and mark one of these bugs as DUPLICATE).

[1] http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.1
[2] http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.8
[3] http://hg.mozilla.org/mozilla-central/file/23f1f0369df5/js/src/builtin/Date.js#l81
[4] http://www.ecma-international.org/ecma-402/1.0/#ToLocalTime

Comment 12

[ipsecog]

Another wrong date: 1974-05-25 shows as 1974-05-24.

Comment 13

[marcbustier]

I can confirm the error. In my case the correct date is 1970-06-05. It is shown as 1970-06-04.

Comment 14

[Mark C]

I've been hit by this issue in the webapp I develop. Whilst I basically understand the cause of the problem, it seems ludicrous that this can happen:

console.log(new Date("1975", "9", "27").toLocaleString());
// 27/10/1975 00:00:00

console.log(new Date("1974", "9", "27").toLocaleString());
// 26/10/1974 23:00:00

Comment 15

[Rainer Bielefeld]

Is this one really different from "Bug 1139167 - Some birthdays are off by one day in Thunderbird's addressbook", what has been fixed in between?

Comment 16

[Magnus Melin [:mkmelin]]

Yes. Thunderbird worked around it using UTC-based calculations.

Comment 17

[Todd]

Having programed many years for date logic I cannot see why this would have anything to do with DST.  DST changes by an hour that would mean that Birthday's were tied to times of day which shouldn't be the case.  Not all countries nor timezones even have DST.

That being said when you look in the calendar at the properties of a person's B-day it says it starts on 10/7/2015 All Day and ends on 10/8/2015 All Day (the first is the right date).  I've never seen this behavior before so it must be something new that's been introduced.

When I click on the event detail it takes me to Google which says Wed, October 7, 12am – Thu, October 8, 12am and it should be Wed, October 7, 12am - Wed, October 7 12:59pm.

I'm wondering if it's a calendar induced problem?

Comment 18

[André Bargull [:anba]]

Dup'ing forward to bug 1346211 which should have fixed this problem. Please reopen if the issue is still present. Thanks!