Daylight Savings leap bugs?

[Adam Peller]

I've encountered a couple of surprising behaviors in Date relative to
daylight savings rules in certain timezones. The first appears to be
specific to FF and a host platform on the Unix epoch date:

https://bugzilla.mozilla.org/show_bug.cgi?id=487897
1
// you'd expect 0

which is unfortunate, since time=0 is often used in Date calculations.

The second problem appears in most browsers I've tested. In essence,
construct a Date object for the day where summer time begins in
Argentina, and it throws you back an hour to the previous day:

http://bugs.dojotoolkit.org/ticket/9366
Sat Oct 17 2009 23:00:00 GMT-0300 (ART)

Because the date shift occurs at midnight, perhaps there really is no
'midnight' that day? I'm wondering why it throws me backwards instead
of forwards, unless this is a bug in some algorithm which assumes
northern hemisphere rules? Using Date as a container for month and
date, especially in local time, clearly has its problems, but I think
it's generally expected behavior that the date remain constant. Is
this a bug in JS? In the host OS? Or does this actually make sense to
anyone? Generally speaking, are there rules for what should happen
during a dst leap, particularly on the boundary?

-Adam

 

[Thomas 'PointedEars' Lahn]

I've encountered a couple of surprising behaviors in Date relative to
daylight savings rules in certain timezones. The first appears to be
specific to FF and a host platform on the Unix epoch date:

https://bugzilla.mozilla.org/show_bug.cgi?id=487897

You can bet that will become INVALID, WONTFIX. There is no bug as you will
see shortly.

1
// you'd expect 0

You would _not_. The hour of the date value is clearly 1 (you said so
yourself!); Epoch is defined as 1970-01-01 (CE) 00:00 _UTC_ (which for all
intents and purposes is GMT+0000), and so 1970-01-01 01:00:00 GMT+0100.

which is unfortunate, since time=0 is often used in Date calculations.

new Date(0)

will get you Epoch a bit more efficient. While it will be a date value with
a time zone offset according to the client (there is no bug), DST does not
enter into it since DST did not and does not start or end anywhere near New
Year's Day in any country.

The second problem appears in most browsers I've tested. In essence,
construct a Date object for the day where summer time begins in
Argentina, and it throws you back an hour to the previous day:

http://bugs.dojotoolkit.org/ticket/9366

Sat Oct 17 2009 23:00:00 GMT-0300 (ART)

That's another reason why one wouldn't rely on the client time for a Web
application.

Because the date shift occurs at midnight, perhaps there really is no
'midnight' that day?

There is, of course. 01:00 GMT-0200 is 00:00 GMT-03:00.

I'm wondering why it throws me backwards instead of forwards,

Because DST *ends* later that day and thus clocks are to be set an hour
backwards then. Without having checked the Specification, I presume that
because there is no way of knowing if you mean a value before of after the
switching, it picks the most probable time zone for that day (2000-08-18)
and your locale which is GMT-0200 (after the switching).

Ceterum censeo DST esse delendam.


PointedEars

 

[Adam Peller]

You would _not_.  The hour of the date value is clearly 1 (you said so
yourself!); Epoch is defined as 1970-01-01 (CE) 00:00 _UTC_ (which for all
intents and purposes is GMT+0000), and so 1970-01-01 01:00:00 GMT+0100.

Whoa, hold on. I'm not dealing with time=0 or UTC in my example
(sorry if I implied otherwise). If I had done something like new Date
(0).getHours() in that time zone or used the UTC function, I
definitely would expect to get a 1, but I'm _not_. I'm constructing
midnight, Jan 1, 1970 in local time, allegedly one hour off from UTC
at that point in time, and asking for the hours back in local time.
That seems to return "0" when I run the test anywhere but IST on FF/
non-Win. Unless this is the same problem of a DST leap occurring
exactly at that moment (as you say, very unlikely) I'd expect getHours
to return me the hours in local time, i.e. midnight. Granted, this is
not the exact epoch, it's the same day as the epoch, and the code
probably should be dealing in UTC, but it's not. Still not a browser
bug? Perhaps we can blame it on the host?

  new Date(0)

will get you Epoch a bit more efficient.

Agreed. That's the Epoch. What I had in my example was not, and that
itself is a bug.

....

There is, of course.  01:00 GMT-0200 is 00:00 GMT-03:00.


Because DST *ends* later that day and thus clocks are to be set an hour
backwards then.

Careful, we're talking about the southern hemisphere. October is when
they leap forward. I guess what I meant to say is that there's no
representation of midnight in that timezone using the JS Date Object
in local time. You could certainly represent the value unambiguously
in UTC, which is what I think the spec suggests... anything else is up
to magical daylight savings algorithms which vary over time (I believe
ES5 is corrected to point this out) All that said, I still can't
understand why it would bump me back to 23h.

-Adam

 

[Doug Miller]

In addition to the errors already pointed out by T. Lahn, there's this one:

Because the date shift occurs at midnight

No, it doesn't. It occurs at 0200 local civil time.
http://www.nist.gov/public_affairs/faqs/qdaylite.htm

 

[Adam Peller]

No, it doesn't. It occurs at 0200 local civil time.http://www.nist.gov/public_affairs/faqs/qdaylite.htm

Ummm... that's in the U.S. Sorry, re-reading my post I realized I
forgot to call out the fact that this bug report indicates problems in
Argentina GMT-0300 (ART)

 

[David Mark]

[snip]

The second problem appears in most browsers I've tested.  In essence,
construct a Date object for the day where summer time begins in
Argentina, and it throws you back an hour to the previous day:

http://bugs.dojotoolkit.org/ticket/9366


Sat Oct 17 2009 23:00:00 GMT-0300 (ART)

When I first read about this issue, it seemed like this was something
that could be avoided (at least for this widget.) Why does the date
selection need to be converted to a JS Date? I would store/send the
selection as three numbers.

Is it to figure offsets or range lengths? ISTM such calculations will
not be a problem. See Stockton's examples. I'm sure if there are
issues with this they have been addressed there.

 

[Thomas 'PointedEars' Lahn]

You would _not_. The hour of the date value is clearly 1 (you said so
yourself!); Epoch is defined as 1970-01-01 (CE) 00:00 _UTC_ (which for all
intents and purposes is GMT+0000), and so 1970-01-01 01:00:00 GMT+0100.

Whoa, hold on. [...] I'm constructing
midnight, Jan 1, 1970 in local time, allegedly one hour off from UTC
at that point in time, and asking for the hours back in local time.

Sorry, my bad. I re-read your posting several times and still confused the
arguments. (Apparently the need for vacation is urgent.)

That seems to return "0" when I run the test anywhere but IST on FF/
non-Win. [...]
ACK

Granted, this is not the exact epoch, it's the same day as the epoch,
and the code probably should be dealing in UTC, but it's not. Still
not a browser bug?

I can't be sure. If the behavior does occur neither in another UA on the
same platform nor in Firefox on another platform, same local time zone
(incl. DST conditions) provided, it probably is a bug.

Perhaps we can blame it on the host?

Why, we can always blame it on the host

Careful, we're talking about the southern hemisphere. October is when
they leap forward.

Of course. But a time zone naturally spans both the northern and the
southern hemisphere, and DST ist much more common on the northern one.
Furthermore, JavaScript was created, and ECMAScript was specified, by people
from the northern hemisphere, so that might have provided additional reason
for a bias.

ART (Argentina Time) is also special because in Argentina there is no fixed
annual schedule for DST, so that may be another explanation as to why you
are set backwards there.

[...] All that said, I still can't understand why it would bump me back
to 23h.

Well, it isn't really "back", is it? The time value would be the same, only
hour and time zone differ from expectations. You can (and apparently
should) use Date.prototype.getTimezoneOffset() to consider the difference in
your computations.


PointedEars

 

[Doug Miller]

blic_affairs/faqs/qdaylite.htm

Ummm... that's in the U.S. Sorry, re-reading my post I realized I
forgot to call out the fact that this bug report indicates problems in
Argentina GMT-0300 (ART)

Indeed you did neglect to specify that. And since you're posting from an IP
address in the U.S. ...

 

[Dr J R Stockton]

In comp.lang.javascript message <54429e6d-86a8-48ff-8d52-f7e6cd9dafa4@o1
4g2000vbo.googlegroups.com>, Wed, 3 Jun 2009 06:54:21, Adam Peller

I've encountered a couple of surprising behaviors in Date relative to
daylight savings rules in certain timezones. The first appears to be
specific to FF and a host platform on the Unix epoch date:

Summer Time rules are not governed by time zones. All EU has the same
rules (assuming UTC=GMT), but covers 3 zones. Russia has one set of
rules, but is in about 11 time zones. Perth & Beijing are in the same
zone, but have different rules. Chile, Venezuela, and Labrador appear
to be in the same zone, but have different rules.


You need to say exactly what the machine and OS are, and to what
location they are set. Unless you write the full story with complete
unambiguity, one cannot be certain what you mean.

https://bugzilla.mozilla.org/show_bug.cgi?id=487897

1
// you'd expect 0

which is unfortunate, since time=0 is often used in Date calculations.

IST has at least three possible meanings in this context.

If IST is supposed to represent Irish Standard Time, you should be aware
that the British Isles, normally with clocks set to GMT in winter, had
them advanced by an hour for three years around that time. The UK did
this by extending the duration of British Summer Time (BST and calling
the time British Standard Time (BST).

The Irish, presumably noting that Summer is longer than Winter, did it
differently. While the Republic of Ireland's clocks were kept in
agreement with those of the UK of GB & NI, the RoI apparently advanced
their Standard Time by one hour and, instead of putting them forward for
the Summer, put them back for the Winter. It seems unclear what they
did at the end of the "extended-summer" period, except that their clocks
continued to agree with UK ones.

Now, in the EU, we all must change the clock at 01:00 UTC (or GMT) on
the last Sundays of March and October; but I don't recall whether we are
permitted to choose between putting them forward for the Summer or back
for the winter.

The "TZ" notation could handle Winter Time by swapping the dates and
using a negative shift; but the detailed grammar may not allow the
nece3ssary minus sign.

The second problem appears in most browsers I've tested. In essence,
construct a Date object for the day where summer time begins in
Argentina, and it throws you back an hour to the previous day:

Wikipedia says that only some of Argentina has Summer Time.

http://bugs.dojotoolkit.org/ticket/9366

Sat Oct 17 2009 23:00:00 GMT-0300 (ART)

Because the date shift occurs at midnight, perhaps there really is no
'midnight' that day?

Consult the Azores setting (or Canaries?). Some such place is an hour
behind GMT in Winter (i.e. like New York, but not as bad), and, if
following EU rules, must change its clocks either to or from midnight
local time.

I'm wondering why it throws me backwards instead
of forwards, unless this is a bug in some algorithm which assumes
northern hemisphere rules? Using Date as a container for month and
date, especially in local time, clearly has its problems,

It is not such. It contains only a count of milliseconds with
1970-01-01 00:00:00 UTC being the Zero Second. There are methods to
calculate, for example, the Month. Timing may be able to demonstrate
that getMonth is slower than getTime.

Reports of offset are obtained by consulting, or by having consulted at
browser load (or ?), the OS for the CURRENT Summer Time Rules for the
set location - OR by asking the OS to convert. There can be no problem
with Windows before Vista, as it only knows one set of rules per
location. AIUI, Vista knows two sets, to handle the US rule change of
2007-03-01 unspecified time; AIUI, a UNIX system knows all. Therefore,
Vista & Unix potentially can commit the sin of using non-current rules
nor non-current dates.

but I think
it's generally expected behavior that the date remain constant. Is
this a bug in JS? In the host OS? Or does this actually make sense to
anyone? Generally speaking, are there rules for what should happen
during a dst leap, particularly on the boundary?

There is ambiguity in the Real World Rules as to whether, for example,
on the last Sunday of March the ideal UK clock will show 01:00 for an
infinitesimal time before changing to 02:00, or whether at the end of
00:59 it will go straight to 02:00. There will also be doubt about what
implementations do.

Example : DOS has 0x1800B0 ticks per day, starting at 0. The code
indicates, IIRC, that the clock actually is set to 0x1800B0, but there
is then a comparison which will set it to 0x0 and set the Tomorrow bit.
But the nature of DOS makes that sequence apparently un-interruptible,
so that user code cannot see 0c1800B0. BTW, in code I saw, the
comparison is for equality; so if one sets the value to 0x1800B0 by a
sort of "Poke" it will continue to rise, TIME shows hours>23, and
eventually confusion sets in.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>, Wed,

new Date(0)

will get you Epoch a bit more efficient. While it will be a date value with
a time zone offset according to the client (there is no bug),

No. The Date Object is an IEEE Double, with Methods. It contains no
offset.

"Time zone offset" is bad terminology, originated by an ill-educated
nerd. Where there is Summer Time, the Offset changes seasonally. But
the Time Zone does not change seasonally; it is only changed (like the
status of Schleswig-Holstein) politically. Method getTimeZoneOffset
should be replaced by getTimeOffset.

DST does not
enter into it since DST did not and does not start or end anywhere near New
Year's Day in any country.

A true Time Zone change, however, could occur after New Year's Eve - boy
most politicians would prefer to do it when the people are more likely
to be, on the whole, sober and asleep.

 

[Dr J R Stockton]

In comp.lang.javascript message <7f50ec38-2227-4f01-9090-3ad1a6c355f8@o1
4g2000vbo.googlegroups.com>, Wed, 3 Jun 2009 09:08:25, Adam Peller

Careful, we're talking about the southern hemisphere. October is when
they leap forward. I guess what I meant to say is that there's no
representation of midnight in that timezone using the JS Date Object
in local time. You could certainly represent the value unambiguously
in UTC, which is what I think the spec suggests... anything else is up
to magical daylight savings algorithms which vary over time (I believe
ES5 is corrected to point this out) All that said, I still can't
understand why it would bump me back to 23h.

Be aware that the Date Object contains only an IEEE Double of
milliseconds UTC from Epoch. A Double represent any millisecond within
2^53 of Epoch (and many others), but a standard-compliant Date Object
can only hold a value not greater in absolute value than 86400000E8,
being 10^8 days. (At least one major browser does not comply - Safari 3
fails Test 09 on my js-datex.htm.)

There are some times that could be plausibly written that JavaScript
will not output, corresponding to what the local clock jumps over in
Spring. It can read such strings.

The Standard does not define sensible conversions between Date & String;
so one cannot expect it to cover difficult cases.

My js-date2.htm can show when the JavaScript clock changes occur for the
current location. Windows 98 got that wrong for the UK.

Opera, up to 9.61 but not 9.64, in Windows XP, did strange things with
UK Summer Time outside 0 <= time_t < 2^31 seconds, which casts doubt
on its internal arrangements.

 

[Adam Peller]

When I first read about this issue, it seemed like this was something
that could be avoided (at least for this widget.)  Why does the date
selection need to be converted to a JS Date?  I would store/send the
selection as three numbers.

We're getting a bit off topic but, well, it's nice to have some
abstraction for a date or date+time when writing library routines.
JavaScript has one, so I think the instinct was to use what's
provided. Dates, unlike an array, are self-descriptive and are likely
to be used in other Date calculations, by this library and other
code. Sure, Dojo could have used a hash object or created its own
Date object, but why should one need to do that? (One reason would be
that Date objects are expensive, but we're talking about a single
instance here)

Over the wire, Dojo best practice is to use ISO formatted dates and
times, exclusively. Programmatically, Date objects seem more
intuitive to deal with, at least when they do what you expect them
to

Is it to figure offsets or range lengths?  ISTM such calculations will
not be a problem.  See Stockton's examples.  I'm sure if there are
issues with this they have been addressed there.

In most examples in Dojo, Date objects are used for a single point in
time or to represent a date where the time portion is ignored, in
which case a Date object really isn't precise (the old date vs
datetime problem) Still, it seems perfectly reasonable to me to use
Date objects to encapsulate either one.

-Adam

 

[Adam Peller]

Indeed you did neglect to specify that. And since you're posting from an IP
address in the U.S. ...

So that's part of the problem. Arrogant Americans, like myself, need
to write code that works everywhere.

 

[David Mark]

We're getting a bit off topic but, well, it's nice to have some
abstraction for a date or date+time when writing library routines.

Of course. I'm just saying we can store it as numbers and then
convert it to Date objects when and as needed.

JavaScript has one, so I think the instinct was to use what's
provided.  Dates, unlike an array, are self-descriptive and are likely
to be used in other Date calculations, by this library and other
code.

Sure. For instance the value property of the widget (I think that was
the name) is a Date, set each time the selection changes. AIUI the
selection is currently stored internally as a Date, which looks like
something we should avoid.

Sure, Dojo could have used a hash object or created its own
Date object, but why should one need to do that?  (One reason would be
that Date objects are expensive, but we're talking about a single
instance here)

I haven't dug too far into the date handling, but I thought Dojo had
its own date-like object.

Over the wire, Dojo best practice is to use ISO formatted dates and
times, exclusively.  Programmatically, Date objects seem more
intuitive to deal with, at least when they do what you expect them
to

Yes. If this widget - for example - had a getDayOfMonth method, it
would be hard-pressed to extract it from a Date and match the user's
selection (at least in Argentina.)

In most examples in Dojo, Date objects are used for a single point in
time or to represent a date where the time portion is ignored, in
which case a Date object really isn't precise (the old date vs
datetime problem)  Still, it seems perfectly reasonable to me to use
Date objects to encapsulate either one.

I think the former always and the latter sometimes. I think we are
running into a situation with this widget that will call for another
strategy. I'll have to look again at what exactly is broken. The
test page fills in a text input with the proper time, though some
times will not be exactly what you expect due to conversion issues.
As long as that doesn't break the widget, it isn't a problem. But
there was the other issue of typing the date and that was completely
broken for this one date in Argentina. Did you figure out what was
going wrong there?

 

[Adam Peller]

I haven't dug too far into the date handling, but I thought Dojo had
its own date-like object.

Nope. Dojo tries to stay out of the business of doing what core
Javascript already does. We do have a dojo.date package with utility
methods, most of which take Date as an argument, also dojo.date.stamp
for ISO support and dojo.date.locale for CLDR formatting and parsing
for user interaction. Most recently, we've accepted some experimental
packages which create duck-typed objects like Dates to support non-
Gregorian calendars.

I think the former always and the latter sometimes.  I think we are
running into a situation with this widget that will call for another
strategy.  I'll have to look again at what exactly is broken.  The
test page fills in a text input with the proper time, though some
times will not be exactly what you expect due to conversion issues.
As long as that doesn't break the widget, it isn't a problem.  But
there was the other issue of typing the date and that was completely
broken for this one date in Argentina.  Did you figure out what was
going wrong there?

Although I do not understand why JS chooses to repeat the 23rd hour in
this particular case, I'm willing to accept that it's just some 'host
thing' (it occurs on more than one platform, though I have not done a
conclusive test on all platforms I have available) For now, in Dojo
I've simply put in a one hour adjustment to add an hour when there is
such an underflow. That assumes, among other things a one hour
underflow results from such a shift. It applies not just to this
widget, but to the Date parsing logic in dojo.date.locale. You can
examine the changesets in trac in the ticket on my original note.

I post here because I was concerned about the Javascript case, in
general, not the Dojo bug. I figure this is the type of thing someone
is bound to trip over, and most of the time they won't know it, as the
test matrix for running your code against other timezones and daylight
savings rules is large and impossible to automate, if such test cases
were even considered.

 

[David Mark]

[snip]

I think the former always and the latter sometimes.  I think we are
running into a situation with this widget that will call for another
strategy.  I'll have to look again at what exactly is broken.  The
test page fills in a text input with the proper time, though some
times will not be exactly what you expect due to conversion issues.
As long as that doesn't break the widget, it isn't a problem.  But
there was the other issue of typing the date and that was completely
broken for this one date in Argentina.  Did you figure out what was
going wrong there?

Although I do not understand why JS chooses to repeat the 23rd hour in
this particular case, I'm willing to accept that it's just some 'host
thing' (it occurs on more than one platform, though I have not done a
conclusive test on all platforms I have available)  For now, in Dojo
I've simply put in a one hour adjustment to add an hour when there is
such an underflow.  That assumes, among other things a one hour
underflow results from such a shift.  It applies not just to this
widget, but to the Date parsing logic in dojo.date.locale.  You can
examine the changesets in trac in the ticket on my original note.

I post here because I was concerned about the Javascript case, in
general, not the Dojo bug.  I figure this is the type of thing someone
is bound to trip over, and most of the time they won't know it, as the
test matrix for running your code against other timezones and daylight
savings rules is large and impossible to automate, if such test cases
were even considered.

I know. I just think the one-hour underflow assumption is incorrect.
Seems like the time zone offset must be considered. I'll look at the
patch tomorrow. I think I understand what PE was saying about this.
Perhaps he will elaborate in the meantime.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn posted:

No. The Date Object is an IEEE Double, with Methods. It contains no
offset.

However, I get

// Thu Jan 01 1970 01:00:00 GMT+0100 (CET)
new Date(0)

// -60
new Date(0).getTimezoneOffset()

in Firefox 3.0.9/Linux. How do you explain that?

"Time zone offset" is bad terminology, originated by an ill-educated
nerd.

A matter of opinion, and I don't agree.

Where there is Summer Time, the Offset changes seasonally. But
the Time Zone does not change seasonally; it is only changed (like the
status of Schleswig-Holstein) politically. Method getTimeZoneOffset
should be replaced by getTimeOffset.

And yet that offset is directly related to the locale's time zone.

A true Time Zone change, however, could occur after New Year's Eve - boy
most politicians would prefer to do it when the people are more likely
to be, on the whole, sober and asleep.

ACK


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <2d9162d4-7b3c-4a79-8d49-0dc01dd74a36@t1
0g2000vbg.googlegroups.com>, Wed, 3 Jun 2009 11:20:48, David Mark

[snip]

The second problem appears in most browsers I've tested.  In essence,
construct a Date object for the day where summer time begins in
Argentina, and it throws you back an hour to the previous day:

http://bugs.dojotoolkit.org/ticket/9366


Sat Oct 17 2009 23:00:00 GMT-0300 (ART)

When I first read about this issue, it seemed like this was something
that could be avoided (at least for this widget.) Why does the date
selection need to be converted to a JS Date? I would store/send the
selection as three numbers.

Is it to figure offsets or range lengths? ISTM such calculations will
not be a problem. See Stockton's examples. I'm sure if there are
issues with this they have been addressed there.

I knew that removing 'Manipulating times, dates and the lastModified
date and time in javascript:- <http://www.merlyn.demon.co.uk/js-
dates.htm>' from "3.2 What online resources are available?" between FAQ
8.1 & FAQ 9.91 was unhelpful. Note that the wording was crafted to be
found by most reasonable searchers.


As an illustration of the need for exactness in expression : My WinXP
has no "Argentina" setting. It has one for "Buenos Aires" and a number
of others for places nearby that are probably not in Argentina. It also
has "Old" and "New" for Mexico City - but what if the Mexicans make a
second change? AIUI, they did not follow the US change on 2007-03-01.


If the Argies do change at local midnight, Sat/Sun then their Spring
change MUST render all local times BETWEEN 00:00:00 and 01:00:00 non-
existent, PLUS exactly one of those two stated times.


Obvious tests are to try setting 23:00 00:00 01:00 02:00, in each case
exact and a minute off either way; and to do likewise for Autumn.

<http://www.timeanddate.com/time/dst2009.html> - this year, Argentina
changes on Sunday, October 18 & Sunday, March 15 except that parts do
not. And <http://www.timeanddate.com/worldclock/clockchange.html?n=51>
gives details : in Autumn, Saturday seconds 23:00:00 to 23:59:59 are
duplicated; in Spring, Sunday seconds 00:00:00 to 00:23:59 are omitted.


One should note that it is (generally) only necessary to work in Local
Time if new Date() is used other than for timing intervals.
Calendar work can be done with the UTC methods, for anywhere in the
world. Example : Book a hotel room in Podunk, wherever that may be, for
the weekend of the second Sunday in March, Friday 9pm to Sunday 9pm.
You will probably not be given a discount of ~2% for not being there on
Sunday between 2am & 3am. Stay the same times on the weekend of the
last Sunday of October, and you will not expect to be charged an extra
2% for occupying it twice between 1am & 2am.

Using UTC throughout requires a little more typing[*], is more reliable,
and quicker.

Setting a date/time in the clock jump interval, including both ends, is
imprudent. One may know what should happen; but there is no need to
rely on all systems agreeing. Work needing dates but not times can be
more safely done by setting noon rather than midnight (and rounding
differences) - except, maybe, near and on the wrong side of the Date
Line.

[*] Except with <URL:http://www.merlyn.demon.co.uk/js-dobj2.htm>.

 

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 04 jun 2009 in comp.lang.javascript:

However, I get

// Thu Jan 01 1970 01:00:00 GMT+0100 (CET)
new Date(0)

// -60
new Date(0).getTimezoneOffset()

Nothing wrong with that, Thomas, all browsers should and do that.

getTimezoneOffset() is defined as
the GMT minutes offset as seen from the actual local time.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>, Thu,

However, I get

// Thu Jan 01 1970 01:00:00 GMT+0100 (CET)
new Date(0)

// -60
new Date(0).getTimezoneOffset()

in Firefox 3.0.9/Linux. How do you explain that?

It is because you are in, or at least have told your machine that it is
in, the time zone one to the East of here, and that similarly your
settings have no Summer Time for January 1st.

When one calls a Method of Date that needs to know the difference
between Local Time and GMT for the (IEEE Double) value of the Object, it
consults the Time Rules for the location, obtained from the operating
system either on demand or on browser start-up or elsewhen.

You should read ISO/IEC 16262 section 15.9. If a Date Object contained
an Offset field, that would say so. Try reading, too, all sentences of
16262 that contain the string "zone"/"Zone".

You could try setting your machine to UK. If you get the same results,
your Firefox has a known-possible bug, and uses the then-current rather
than the now-current Rules. That bug cannot be available in Windows
before Vista, could but will not be in Vista and probably 7 (UK Rules
have changed more than once since 1970), and AIUI is possible in all
UNIX-type systems since they allowed for the existence of Summer Time
Rules other than the then-current American ones.

A matter of opinion, and I don't agree.

<https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_
Objects/Date/getTimezoneOffset>

You should consult dictionaries for the true meanings of words, not
computer specifications. The Washington Conference of 1884 can also be
considered authoritative.

And yet that offset is directly related to the locale's time zone.

Only secondarily. It depends on the Time Zone, on whether the place
uses Summer Time and if so whether it is Summer and what the chosen
clock change is.

The offset is an offset of time and should be correspondingly named.
TC39 should know that.