Checking for daylight saving

[RobG]

I was investigating a function to determine whether daylight saving
was being observed on a particular date (given the platform's regional
settings) and came across a suggestion at merlyn.com to test the time
zone offset on a variety of dates to see if it changes. Based on
that, I developed the following checkDST() function which, as far as I
can tell, should be sufficient.

It checks either the date passed to it or the current date with 3
other dates, each 3 months further into the future. If any of their
time zones differs from the epoch then either:

true - daylight saving is being observed on the date, or

false - daylight saving is observed but not on the date

are returned. If no difference is found, undefined is returned. I
explicitly return undefined as a matter of style rather than let the
loop peter out and return undefined by default.

Can anyone suggest whether the algorithm is appropriate and if my
implementation is OK? It will fail if there are changes to time zone
offsets that are not related to daylight saving, and if changes occur
for a period of less than 3 months and fall within the dates tested.

As far as I know, there isn't anywhere that does that, but they might
be accommodated by an "acceptable range" test (say allow changes of up
to 5 minutes) and checking for symmetry - if the time zone is
different in x months time, check if it was also different (12 - x)
months ago, and check if it differed by the same amount taking into
consideration the acceptable range.


function checkDST(d) {

d = d || new Date();

var x = new Date(d);
var dt = d.getTimezoneOffset();
var xt;

for (var i=0; i<3; i++) {
x.setMonth(x.getMonth() + 3)
xt = x.getTimezoneOffset();

if (dt != xt) {
return dt < xt;
}
}
return undefined;
}

function showDST(){

var x = isDST(new Date());
var msg;

if (x === true) {
msg = 'Daylight saving is observed here ' +
'and is in force.';
} else if (x === false) {
msg = 'Daylight saving is observed here, ' +
'but not at the moment.';
} else {
msg = 'Daylight saving is not observed here at all.'
}
alert(x + ': ' + msg);
}

showDST();

 

[RobG]

RobG said the following on 12/20/2007 1:27 AM:

That should of course be:

var x = checkDST(new Date());

isDST is not defined. FF2.0
Object Expected. IE7.

Long day today?

:-x bugger...


I changed the name of the function just before posting - does it work
for you? I can't mess with my regional settings for a little while
yet, I'll test it more when I can.

 

[Evertjan.]

Randy Webb wrote on 20 dec 2007 in comp.lang.javascript:

Not for what Rob is wanting to test. The only way to know if it is
getting it correct in different time zones is to change the time zone
settings. It is just as trivial to do that for testing as changing the
time/date. I just didn't do it when I was testing. Right click the
clock on the taskbar in Windows>Adjust Date and Time>Time Zone tab.
Change it, apply it, test it, repeat. There is also a setting there
for automatically changing the time for DST. With it unchecked, the
test gives incorrect results for me when testing my own time zone.

"undefined: Daylight saving is not observed here at all. "

And that is in Eastern Standard Time Zone in the US.

This should work, IMHO:

<script type='text/javascript'>

var d1 = new Date(2007,0,1).getTimezoneOffset()
var d2 = new Date(2007,6,1).getTimezoneOffset()

var t = 'This computer is set for a zone with'

if (d1==d2)
alert(t + 'out summertime offset');
else if (d1>d2)
alert(t + ' summertime offset in Northern hemisphere');
else
alert(t + ' summertime offset in Southern hemisphere');

</script>

IE7 and Central European Time Zone tested.

That such offset saves daylight is absolute nonsense,
though it may save energy consumption.

 

[Dr J R Stockton]

In comp.lang.javascript message <ecae4e75-9e61-4aa0-90ab-6c10978d781e@d4
g2000prg.googlegroups.com>, Wed, 19 Dec 2007 22:27:46, RobG

I was investigating a function to determine whether daylight saving
was being observed on a particular date (given the platform's regional
settings) and came across a suggestion at merlyn.com to test the time

^^^^^^^^^^
I have "American" competition?

zone offset on a variety of dates to see if it changes. Based on
that, I developed the following checkDST() function which, as far as I
can tell, should be sufficient.

It checks either the date passed to it or the current date with 3
other dates, each 3 months further into the future.

Checking the date in question, and January 1st, and July 1st, should
suffice - unless someone does something silly with Summer Time. ISTR
that Australia fiddled the rules for the Olympics, but probably not
enough to matter.

Can anyone suggest whether the algorithm is appropriate and if my
implementation is OK? It will fail if there are changes to time zone
offsets that are not related to daylight saving, and if changes occur
for a period of less than 3 months and fall within the dates tested.

ISO/IEC 16262 requires that the CURRENT Summer Time rules are applied
for ALL years. Most OSs only know one set of rules per location, but
AIUI Vista knows up to 2 sets, and changes.

US legislation, IIRC, changed the rules with effect from 2007-03-01
(presumably local time; possibly DC time). Therefore, Randy et al
should have stopped running Javascript on pre-Vista PCs before
2007-02-28 24:00 LCT, should have updated their systems, and not
restarted Javascript before 2007-03-01 00:00 LCT.

I don't know whether Vista does it right.

Some systems, IIRC, using UNIX, get the OS to do date work that
Javascript ought to do; in that case, the wrong (by 16262) rules or zone
may be applied to non-current dates.

I recall no provision for changing time zone at a location, other than
by the Control Panel settings.


-----

I recall no complaints about <URL:http://www.merlyn.demon.co.uk/js-
dates.htm#YS> first half.



NOTE : Summer Time does NOT change the Time Zone; it only changes the
offset from GMT.


You have

function checkDST(d) {
d = d || new Date();
var x = new Date(d);

If d is not supplied, or is 1970-01-01 00:00:00.000 UTC, or is 0, or is
NaN, both new Date() and new Date(d) will be called and the latter would
be better as new Date(+d). If d is supplied as a string, new Date() may
get it wrong. Under-tested.

Less flexibility would be safer? insist on a Date Object, and copy it -
or maybe

function checkST(d) { var U
d = d == U ? new Date() : new Date(+d)

 

[Evertjan.]

Randy Webb wrote on 21 dec 2007 in comp.lang.javascript:

It tells me I have a summertime offset in Northern hemisphere, but, it
doesn't tell me whether I use Daylight Savings Time or not. No setting
on the PC can either. Arizona, USA, is split on DST. Parts of the
state use it and parts don't. Indiana was another state that just
recently started using it.

Do you mean if you are using summertime offset at present?

That is a simple extension:


<script type='text/javascript'>

var d1 = new Date(2007,0,1).getTimezoneOffset()
var d2 = new Date(2007,6,1).getTimezoneOffset()
var dn = new Date().getTimezoneOffset()

var t = 'This computer is set for a zone with'

if (d1==d2)
alert(t + 'out summertime offset');
else if (d1>d2) {
z = t + ' summertime offset in Northern hemisphere\n';
if (dn==d1)
alert(z + 'At present the offset is off');
else
alert(z + 'At present the offset is on');
};
else
{
z = t + ' summertime offset in Southern hemisphere\n';
if (dn==d2)
alert(z + 'At present the offset is off');
else
alert(z + 'At present the offset is on');
};

</script>

Not tested for Southern hemisphere

It doesn't "save daylight", it just changes the hours in the day when
it is there. Personally, I wish they would just do away with the
entire concept as it is a broken phenomenon now.

Which would be even more terrible for the
'JS Date() cum Windows settings object'
then the crap of the present implementation.
Does it know when this summertime concept started in each zone?
Does the London local setting know about the "double summertime" of WWII?

 

[Evertjan.]

Randy Webb wrote on 21 dec 2007 in comp.lang.javascript:

-Lost said the following on 12/20/2007 9:24 PM:

What congress?

Do you mean 'congress' in the sense of the Kamasutra
and changing a stand of such congress at the last moment?

Wouldn't that put you off, Lost?

<shrug> Why do politicians do any of the things they do?

One reason I read (and don't know if it is true or not) is:

A new law to extend DST to the first Sunday in November will take effect
in 2007, with the purpose of providing trick-or-treaters more light and
therefore more safety from traffic accidents.

What law?

Is that what politicians do, Randy, changing a stand at the last moment?

 

[Dr J R Stockton]

Not for what Rob is wanting to test. The only way to know if it is
getting it correct in different time zones is to change the time zone
settings.

But can one be certain, in Windows, that such a temporary change cannot
possibly have a lasting adverse effect, such as but not limited to
entries in calendar/diary software and limited-duration software that
looks for time reversal or performing scheduled activity?

It is just as trivial to do that for testing as changing the
time/date. I just didn't do it when I was testing. Right click the
clock on the taskbar in Windows>Adjust Date and Time>Time Zone tab.
Change it, apply it, test it, repeat. There is also a setting there for
automatically changing the time for DST. With it unchecked, the test
gives incorrect results for me when testing my own time zone.

"undefined: Daylight saving is not observed here at all. "

And that is in Eastern Standard Time Zone in the US.

Well, if DST is turned off one must expect it not to be found.
Obviously great care must be taken with the wording of such messages.

 

[Evertjan.]

Randy Webb wrote on 21 dec 2007 in comp.lang.javascript:

It should. It has a setting to let Windows change the time for you. By
law, in the USA, it always starts and ends on the same days every
year, no matter what zone you are in in the USA, if you use it.

That gives two nights that this offset is rippling though your continent,
and must be terrible for large organisations like radio/tv.

The European law switching at the same time across all timezones is
slightly better.

No idea.

In general, MS-windows zones surely cannot fill in the historical patchwork
of summertime regions.

<http://en.wikipedia.org/wiki/Daylight_saving_time>
points to an European viewpoint:

Guess whose!

 

[Tom]

I was investigating a function to determine whether daylight saving
was being observed on a particular date (given the platform's regional
settings) and came across a suggestion at merlyn.com to test the time
zone offset on a variety of dates to see if it changes. Based on
that, I developed the following checkDST() function which, as far as I
can tell, should be sufficient.

It checks either the date passed to it or the current date with 3
other dates, each 3 months further into the future. If any of their
time zones differs from the epoch then either:

true - daylight saving is being observed on the date, or

false - daylight saving is observed but not on the date

are returned. If no difference is found, undefined is returned. I
explicitly return undefined as a matter of style rather than let the
loop peter out and return undefined by default.

Can anyone suggest whether the algorithm is appropriate and if my
implementation is OK? It will fail if there are changes to time zone
offsets that are not related to daylight saving, and if changes occur
for a period of less than 3 months and fall within the dates tested.

As far as I know, there isn't anywhere that does that, but they might
be accommodated by an "acceptable range" test (say allow changes of up
to 5 minutes) and checking for symmetry - if the time zone is
different in x months time, check if it was also different (12 - x)
months ago, and check if it differed by the same amount taking into
consideration the acceptable range.


function checkDST(d) {

d = d || new Date();

var x = new Date(d);
var dt = d.getTimezoneOffset();
var xt;

for (var i=0; i<3; i++) {
x.setMonth(x.getMonth() + 3)
xt = x.getTimezoneOffset();

if (dt != xt) {
return dt < xt;
}
}
return undefined;
}

function showDST(){

var x = isDST(new Date());
var msg;

if (x === true) {
msg = 'Daylight saving is observed here ' +
'and is in force.';
} else if (x === false) {
msg = 'Daylight saving is observed here, ' +
'but not at the moment.';
} else {
msg = 'Daylight saving is not observed here at all.'
}
alert(x + ': ' + msg);
}

showDST();

I don't know if you could find something that is reliable and accurate in the
long run. As an example I'm in the Pacific time zone and our government
arbitrarily decided to extended the length of Daylight Savings.

I think you can collect the time zone information
(http://www.w3schools.com/jsref/jsref_obj_date.asp), but I don't think there is
any information there to determine if a timezone used daylight savings or not.

Tom

 

[The Magpie]

Randy Webb wrote on 20 dec 2007 in comp.lang.javascript:

Not for what Rob is wanting to test. The only way to know if it is
getting it correct in different time zones is to change the time zone
settings.[snip]

Ok - so you *do* all know this is a waste of time don't you? There is
one and only one way to do it. You get the user to state explicitly
what time zone they are in, then you check the *actual* date and time
in that time zone (not the one on the PC - so you will need a remote
time-server somewhere) and then you apply the rules in force in that
specific time zone.

And anyone who wants to do that in Javascript is completely insane!

You have one - count them - *one* choice only. Find a way to ask the
operating system and presume the operating system has the time zone
details *and* rules set as the user wants them. Then check a remote
time-server. Even then, it may not be correct because, of course, the
user may choose to set his or her PC to - let's say - GMT because he
likes to do amateur astronomy and it makes it easier.

 

[Dr J R Stockton]

-Lost said the following on 12/20/2007 9:24 PM:

<shrug> Why do politicians do any of the things they do?

One reason I read (and don't know if it is true or not) is:

A new law to extend DST to the first Sunday in November will take
effect in 2007, with the purpose of providing trick-or-treaters more
light and therefore more safety from traffic accidents.

You can find the exact wording on the Web at a USG-type site.
You can find the URL of it in my <uksumtim.htm>, where you can also find
the exact words in a format similar to that of USG.

Try putting congress daylight saving H.R.6 in an IE address bar and
then using Go .

Did you know that the next day on which a Congressional, but not a
Presidential, election will be held in the USA will be (except maybe in
Arizona and Hawaii) in Summer Time?

 

[Dr J R Stockton]

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

var d1 = new Date(2007,0,1).getTimezoneOffset()
var d2 = new Date(2007,6,1).getTimezoneOffset()
var dn = new Date().getTimezoneOffset()

var t = 'This computer is set for a zone with'

if (d1==d2)
alert(t + 'out summertime offset');
else if (d1>d2) {
z = t + ' summertime offset in Northern hemisphere\n';
if (dn==d1)
alert(z + 'At present the offset is off');
else
alert(z + 'At present the offset is on');
};
else
{
z = t + ' summertime offset in Southern hemisphere\n';
if (dn==d2)
alert(z + 'At present the offset is off');
else
alert(z + 'At present the offset is on');
};

Not quite right. Zones are geographically fixed (until a change is
made), and there is no Summer Time concept in them.

Windows XP is set for *places* such as Sri Jayawardenepura, for which it
knows the Zone and the Summer Time rules. There is a checkbox to
enable/disable Summer Time, initialised in accordance with the location;
but if one selects Beijing the box vanishes. Naturally, their
terminology is slipshod.

Which would be even more terrible for the
'JS Date() cum Windows settings object'
then the crap of the present implementation.
Does it know when this summertime concept started in each zone?
Does the London local setting know about the "double summertime" of WWII?

Windows up to XP knows of only one set of rules per location, the
current rules. When the rules change, one should ideally perform the
update at the instant that the legislation becomes effective -
2007-03-01 00:00:00 undefined offset from UTC in the USA this year.

Vista knows up to two sets of rules, AIUI, and a changeover date/time.

But if you read 16262, or 262, you will see that Javascript is required
to use the current rules for all dates.

And if you read <js-date?.htm> you will IIRC see a report that some UNIX
systems get that wrong, using the rules that applied on the date in
question.

 

[Dr J R Stockton]

Evertjan. said the following on 12/21/2007 3:33 AM:

No, whether the location I am in observes Daylight Savings Time. If you
look in Windows XP (not sure what other Win OS'es have it), in the Date
and Time Properties>Time Zone tab, there is an explicit setting for
Indiana(East). That is because Indiana, USA did not use DST for a long
time. You won't find a setting for Arizona, USA, in that list. Yet,
there are parts of Arizona that do, and parts that do not, use Daylight
Savings Time. Yet, the Time Zone is the same whether they use it or
not. The OS has no way of knowing that.

There is no way of telling the exact location, so in Arizona it cannot
as supplied know whether the location has DST or not. That is why
there's a checkbox in XP for turning it on & off.

Windows, if MS does its job right (Win98 got it wrong) knows current UK
Summer Time rules, and has checked the box in installation If I uncheck
it, the machine will show UT (GMT) permanently, as it would if I set
Reykjavik.

How would it be "even more terrible" if there were no such thing as
Daylight Savings Time?


It should.

It does not; except that Vista can know of the most recent change, which
*could* be when it was first used in a location (not a zone). Labrador
and Chile are in the same time zone; but would use opposite Summer Time
changes.

It has a setting to let Windows change the time for you. By law, in
the USA, it always starts and ends on the same days every year, no
matter what zone you are in in the USA, if you use it.

The same days? The dates vary, being 0-6 days before -03-14 &-11-07.
They're (very probably) not even always the same ISO 8601 yyyy-Www-d
(there will be 2 possible values for ww).

It will not; and if it did Javascript would not be allowed to use that
unless the system date was set back to WWII.

 

[Dr J R Stockton]

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

Randy Webb wrote on 21 dec 2007 in comp.lang.javascript:

Canada is more liberal there; the provinces decide. AFAIK they've
"always" used the US dates, but with some variation in time.

That gives two nights that this offset is rippling though your continent,
and must be terrible for large organisations like radio/tv.

AIUI, they have comparatively little of that sort of thing. However,
the Russians, with 11(?) zones, know what to do; and likewise the
Australians, if they ripple-change.

There'll be problems when all of Russia joins the EU; either there'll be
a break-in-system, or in Kamchatka they'll change clocks after Monday
breakfast.

 

[Dr J R Stockton]

Dr J R Stockton said the following on 12/20/2007 5:40 PM:

It doesn't take anything that naive to fool it. Simply telling my PC
not to change the time for me is enough to cause Rob's function to give
incorrect results.

If you lie to your machine, you must be ready to receive lies back. Rob
may need more subtle wording.

What US legislation also does is make it a local decision as to whether
it is used or not. Witness Arizona in the USA.

Yes, and that power did not change.

I know of no US legislation on the date at which a location can change
from one rule set to another, as (much of?) Indiana did. H.R.6
stipulated 2007-03-01, maybe without fullest consideration.

You can get to it without going into the Control Panel but it changes
it in the same place. Right click the clock on the Windows
Taskbar>Adjust Date/Time.

Yes, but that's merely another route to the same settings.

 

[Evertjan.]

Dr J R Stockton wrote on 21 dec 2007 in comp.lang.javascript:

It will not; and if it did Javascript would not be allowed to use that
unless the system date was set back to WWII.

So when localized to London, England, executing:

<script type='text/javascript'>

var t = new Date(1943,7,7,14);
var s = t.toUTCString();
document.write(s);

</script>

Would NOT show the correct:

Sat, 7 Aug 1943 12:00:00 UTC

?

I pity the first time traveler with a Vista OSed laptop,
for being to late for tea.

So should we stick to UTC,
or do without the date object altogether,
for such time computing?

 

[Evertjan.]

Dr J R Stockton wrote on 21 dec 2007 in comp.lang.javascript:

AIUI, they have comparatively little of that sort of thing. However,
the Russians, with 11(?) zones, know what to do; and likewise the
Australians, if they ripple-change.

There'll be problems when all of Russia joins the EU; either there'll be
a break-in-system, or in Kamchatka they'll change clocks after Monday
breakfast.

Not having to get out of bed is such cold places could be a bonus,
someyears I did the same.

What about Vladiwostok?

 

[Dr J R Stockton]

I don't know if you could find something that is reliable and accurate in the
long run. As an example I'm in the Pacific time zone and our government
arbitrarily decided to extended the length of Daylight Savings.

Your elected politicians chose to do so, after a public discussion.
That's how democracy works in all but the smallest societies.

I think you can collect the time zone information
(http://www.w3schools.com/jsref/jsref_obj_date.asp), but I don't think there is
any information there to determine if a timezone used daylight savings or not.

Time Zones are geographically fixed, with occasional changes of borders
as above; they extend from pole to pole. Having Summer Time is a local
choice; equatorial locations do not need it; I think it does not help
near-polar locations; those in the other (N/S) hemisphere change
according to their seasons. By definition, Time Zones give just the
Winter offset from GMT; they don't say whether January or July is in
Winter.

Information covering all but the most unimportant regions is held by
Windows; do you not recall that MS offered an update for the US rule
change earlier this year?

 

[Dr J R Stockton]

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

Dr J R Stockton wrote on 21 dec 2007 in comp.lang.javascript:


So when localized to London, England, executing:

<script type='text/javascript'>

var t = new Date(1943,7,7,14);
var s = t.toUTCString();
document.write(s);

</script>

Would NOT show the correct:

Sat, 7 Aug 1943 12:00:00 UTC

It shows Sat, 7 Aug 1943 13:00:00 UTC which is correct by current
Javascript standards but not in accordance with history.

Likewise, Sat Aug 7 15:00:00 UTC+0100 1943 is given by
document.write(new Date(Date.UTC(1943,7,7,14)));


Windows uses the same setting for Dublin as for London, and so cannot
know (or at least admit) that a century ago Ireland used Dublin Mean
Solar Time.

When the UK, around 1970, tried year-round Summer Time, the Republic or
Ireland considered it wise to make their clocks match ours. But,
looking at their legislation, they actually moved to your Time Zone and
did not otherwise change anything.

I pity the first time traveler with a Vista OSed laptop,
for being to late for tea.

So should we stick to UTC,
or do without the date object altogether,
for such time computing?

If the actual time (new Date()) is not relevant, it is safer to work in
UTC (or in Local Winter time). If speed matters, ISTM likely that an
optimised method using integer arithmetic will generally beat even a
method using UTC in Date Objects.

I occasionally, as you may have noticed, change pieces of my date code
from local to UTC.

 

[Evertjan.]

Dr J R Stockton wrote on 22 dec 2007 in comp.lang.javascript:

I occasionally, as you may have noticed, change pieces of my date code
from local to UTC.

I think, as you may have guessed, that JS Date()'s UTC support is a mess.

It would have been better to have all methods have a attribute
having them interact directly with the internal UTC date/time value of
any Date() object.

dateObj.getDate('UTC')
in stead of
dateObj.getUTCDate()
etc.

That way we could define functions,
that would work both for local time as for UTC:

function manipulateTimeDate(myDate,UTCorNot) {
.....;
.....;
return myDate.getUTCDate(UTCorNot);
};

var nrDate = manipulateTimeDate(thatDate);

var UTCnrDate = manipulateTimeDate(thatDate,'UTC');

====================================

btw, ever replied upon this in MS scripting 5.6?

===========
dateObj.getVarDate()

Remarks
The required dateObj reference is a Date object.

The getVarDate method is used when interacting with COM objects, ActiveX®
objects or other objects that accept and return date values in VT_DATE
format, such as Visual Basic and VBScript.

The actual format is dependent on regional settings and should not be
replied upon within JScript.
============

"replied upon" ??

MS-JS being unreplyable, MS seems to have a lot to answer for.