JavaScript Date gives incorrect information for daylight saving time in March 2007

RESOLVED INVALID

Status

()

Core
JavaScript Engine
RESOLVED INVALID
11 years ago
9 years ago

People

(Reporter: Twinkle, Unassigned)

Tracking

1.8 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: FireFox 2.0.0.1

The Daylight saving time in 2007 occurs on march 11. In my Javascript code, the changes are working fine from April (which has been the usual time change) but not for March. Can you please look into it?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
You're going to have to provide more context than that I think. eg: example javascript and explicit steps to reproduce.
(Reporter)

Comment 2

11 years ago
Here's my code

<html>
<body>
<script>

//You have to set the UTC timezone offset for each location here.
var locationOffsets = {"us" : -8,  "uk" : 0,  "australia" : 10}

//The offset in minutes when an event occurs during active DST. Note: (usually +/- 60 minutes but there are places that change by +/- 30 minutes -- India for example).
var dstOffsets = {"us" : -60, "uk" : 0,  "australia" : 60}

function Event(location, year, month, day, hour, minute, amPm, isDST)
{ 
  this.location = location;
  var utcOffset = locationOffsets[location];
  this.date = new Date();
  this.date.setUTCFullYear(year, month - 1, day);
  this.date.setUTCHours(hour + ((amPm.toLowerCase() == "pm") ? 11 : -1) - utcOffset, minute - ((isDST) ? dstOffsets[location] : 0), 0, 0);
}
Event.prototype.getDay = function () {
  var arr = this.date.toString().split(" ");
  arr.length = 3;    
  var arrJoin = arr.join(" ");
  var arrDay = arrJoin.substring(0, 3);
  var arrMon = arrJoin.substring(4, 7);
  var arrDate = arrJoin.substring(8);  

  if (arrDate.search("0") == 0)
  {
    arrDate = arrDate.replace(/0/, "");
  } 
  return arrMon + " " + arrDate + ", " + arrDay.toUpperCase();
}

Event.prototype.getTime = function () {
  var hours = this.date.getHours() + 1;
  var minutes = this.date.getMinutes();
  var amPm = "AM";
  
if (hours > 11 && hours < 24) {
   hours = hours - 12;
   amPm = "PM";
} 
 if (hours == 0 || hours == 24) hours = 12;

  if (minutes <10) { minutes = "0"+minutes};
  return ""+hours+":"+minutes+" "+amPm;   
}

var FOSDTETME_0109UK = new Event("uk", 2007, 4, 25, 6, 00, "pm");
var FOSDTETME_0425USA = new Event("us", 2007, 4, 25, 5, 00, "pm");
var FOSDTETME_0425AUS = new Event("australia", 2007, 4, 25, 5, 00, "pm");

document.write("UK:::" + FOSDTETME_0109UK.getDay());
document.write(" " + FOSDTETME_0109UK.getTime());

document.write("<br><br>USA:::" +FOSDTETME_0425USA.getDay());
document.write(" " +FOSDTETME_0425USA.getTime());
document.write("<br><br>AUS:::" +FOSDTETME_0425AUS.getDay());
document.write(" " +FOSDTETME_0425AUS.getTime());
</script>
</body>
</html>
Created attachment 249934 [details]
code from comment 2

I don't know what I'm supposed to be seeing with this..

Comment 4

11 years ago
Created attachment 249941 [details]
code from comment 2 (fixed)

Updated version (fix the "The offset in minutes..." comment).
I don't see what's wrong neither. 

My output:
In March
UK:::Mar 11, SUN 7:00 PM
USA:::Mar 12, MON 2:00 AM
AUS:::Mar 11, SUN 8:00 AM
In April
UK:::Apr 25, WED 8:00 PM
USA:::Apr 26, THU 3:00 AM
AUS:::Apr 25, WED 9:00 AM

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20061229 Minefield/3.0a2pre ID:2006122904 [cairo]
Attachment #249934 - Attachment is obsolete: true
(Reporter)

Comment 5

11 years ago
Created attachment 249948 [details]
Daylight Saving Time for Javascript code

Here's what I am trying to do. Our company is located in SFO. We offer online seminar and we need to display the event time in the local time and not SFO time in the schedule page. For example, if the seminar starts at 11am on Jan 2 in SFO, it should show as 7pm if I am in UK. The issue is with the DST for March 14. The code is displaying one hour behind but no problem for the April seminar events.

I am having this issue for both Firefox and IE. If you are the team to help me, please let me know where to send this issue to get fixed for our website. Highly appreciate your help. Thanks

The event time should be 6pm on march 11 but my code is displaying 5pm. But the same code works fine for April 2 - event time is displaying as 6pm due to the DST. Let me know if you need additional information.

Comment 6

11 years ago
The browsers get the time zone information from the OS, so this is a Windows problem. See this article for more information:
http://www.microsoft.com/windows/timezone/dst2007.mspx
With the testcase in comment 4 (thanks for fixing that obvious oversight) I get the same output with Opera 9.1, IE6 and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20061229 Minefield/3.0a2pre ID:2006122904 [cairo]:

In March
UK:::Mar 11, SUN 6:00 PM
USA:::Mar 12, MON 1:00 AM
AUS:::Mar 11, SUN 7:00 AM

In April
UK:::Apr 25, WED 7:00 PM
USA:::Apr 26, THU 2:00 AM
AUS:::Apr 25, WED 8:00 AM

Since three browsers here all show the same thing, this suggests it's not a bug in firefox, and so perhaps this bug should be marked INVALID.

Updated

11 years ago
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Summary: Javascript error → JavaScript Date gives incorrect information for daylight saving time in March 2007
Version: unspecified → 1.8 Branch

Comment 8

11 years ago
I don't have the ECMAScript specs in front of me, but I'm told that historical time zone data is NOT supposed to be taken into account when doing DST calculations in JavaScript.  In other words, JS is supposed to do brain-dead date calculations for such things.  (I'll try to find a spec reference.)

Per Comment #6, this is not currently the case for Firefox.  Should it be, or should the spec be updated because it's trying to over-simplify the solution to the problem?

The other issue is, since DST calculations are based on on commonly-accepted dates, should those change since DST start/end is changing in the U.S. this year, or should they remain the same?

Note that this issue is being tracked for Safari on this bug:

http://bugs.webkit.org/show_bug.cgi?id=12975

Comment 9

11 years ago
(In reply to comment #8)
> I don't have the ECMAScript specs in front of me, but I'm told that historical
> time zone data is NOT supposed to be taken into account when doing DST
> calculations in JavaScript.  In other words, JS is supposed to do brain-dead
> date calculations for such things.  (I'll try to find a spec reference.)
> 
> Per Comment #6, this is not currently the case for Firefox.  Should it be, or
> should the spec be updated because it's trying to over-simplify the solution to
> the problem?

ECMAScript-262, Section 15.9.1.9:

http://www.ecma-international.org/publications/standards/Ecma-262.htm

> The other issue is, since DST calculations are based on on commonly-accepted
> dates, should those change since DST start/end is changing in the U.S. this
> year, or should they remain the same?

My reading of the spec says that JavaScript should implement the "current algorithm" for determining DST, which means if this were done (in the U.S.) all dates before 2007 would now shift to start in the new dates (second Sunday in March, first Sunday in November).  That doesn't seem like a good thing.

Is there any reason why JavaScript shouldn't let the underlying O/S provide this information instead as Firefox apparently does now?

The spec is wrong. The browsers agree, and we will fix the Fourth Edition of ECMA-262 to reflect this de-facto standard. INVALID.

/be
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
Actuall, no spec change is needed. From the spec:

15.9.1.8 Daylight Saving Time Adjustment

An implementation of ECMAScript is expected to determine the daylight saving time algorithm. The algorithm to determine the daylight saving time adjustment DaylightSavingTA(t), measured in milliseconds, must depend only on four things: 

(1) the time since the beginning of the year

  t – TimeFromYear(YearFromTime(t))

(2) whether t is in a leap year

  InLeapYear(t)

(3) the week day of the beginning of the year

  WeekDay(TimeFromYear(YearFromTime(t))

and

(4) the geographic location.

The implementation of ECMAScript should not try to determine whether the exact time was subject to daylight saving time, but just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time. This avoids complications such as taking into account the years that the locale observed daylight saving time year round.

If the host environment provides functionality for determining daylight saving time, the implementation of ECMAScript is free to map the year in question to an equivalent year (same leap-year-ness and same starting week day for the year) for which the host environment provides daylight saving time information. The only restriction is that all equivalent years should produce the same result. 
----

So comment 6 has it right. This is a Windows problem.

/be
(In reply to comment #11)
> Actuall, no spec change is needed. From the spec:
> 
> 15.9.1.8 Daylight Saving Time Adjustment
> 
> An implementation of ECMAScript is expected to determine the daylight saving
> time algorithm. The algorithm to determine the daylight saving time adjustment
> DaylightSavingTA(t), measured in milliseconds, must depend only on four things: 
> 
> (1) the time since the beginning of the year
> 
>   t – TimeFromYear(YearFromTime(t))
> 
> (2) whether t is in a leap year
> 
>   InLeapYear(t)
> 
> (3) the week day of the beginning of the year
> 
>   WeekDay(TimeFromYear(YearFromTime(t))
> 
> and
> 
> (4) the geographic location.
> 
> The implementation of ECMAScript should not try to determine whether the exact
> time was subject to daylight saving time, but just whether daylight saving time
> would have been in effect if the current daylight saving time algorithm had
> been used at the time. This avoids complications such as taking into account
> the years that the locale observed daylight saving time year round.
> 
> If the host environment provides functionality for determining daylight saving
> time, the implementation of ECMAScript is free to map the year in question to
> an equivalent year (same leap-year-ness and same starting week day for the
> year) for which the host environment provides daylight saving time information.
> The only restriction is that all equivalent years should produce the same
> result. 
> ----

So per the spec, JavaScript engines should be updated so that in the United States, the DST algorithm starts on the second Sunday in March and ends on the first Sunday in November.  This also means that Mar 11, 2006 through Mar 31, 2006 and October 28, 2006 through November 4, 2006 suddenly become DST dates when they were not the previous year.

If that is correct, it seems to me that this behavior was easily forgiven before when the previous dates affected were in the 1940s (before the "modern" computer age), but it's a bit more disturbing when dates less than a year ago suddenly start behaving differently.  :(

You're right, the ECMA spec was naive. Now that policritters have messed with DST in a big way, the simplistic design should be revisited. Indeed if major browser implementations rely on the OS for all DST information, and the OS does retain historical knowledge, then the de-facto standard is more what you want, and not what ECMA-262 specifies.

This is a bug for ECMA TG1, so not a bugzilla report. If you are game, please join and mail to es4-discuss@mozilla.org (use es4-discuss-request@m.o to subscribe) citing this bug and raising the issue. Or if you're too busy, I will make time to do this (later this week probably). Thanks,

/be

Comment 14

11 years ago
Filed as bug 129 in the ES4 Trac database.

Comment 15

9 years ago
Please review the proposed wording at http://bugs.ecmascript.org/ticket/129#comment:8 to see whether it is consistent with the de-facto standard. Last chance to fix this for ES5!
You need to log in before you can comment on or make changes to this bug.