In comp.lang.javascript message <
[email protected]
And watch it go belly-up in all browsers other than Opera. :-(
But I wrote "to represent"; I did not supply a prepared string. It
needs to be done twice in that depressing code.
While that format might be ISO correct, the best format (i.e.
acceptable in a wide variety of browsers) for a date string I have
found is:
new Date( 'yyyy/mm/dd hh:mm:ss' );
I know I used to think that was safe, except maybe for years before 1000
or 100. I don't know whether I'm quite so sure now.
H'mm - in IE6, new Date( '11/11/11 11:11:11 ' ) is in year 1911
but new Date( '11/11/11 11:11:11 AD' ) is in year 11
and, expectedly, new Date( '22/11/22 11:11:11 AD ' ) is in year 23
Attempting strict ISO compliance, time zones, or fractions of seconds
is doomed I'm afraid in most browsers.
Incidentally, if I create a date object in the future, say:
var t = new Date( '2010/01/01 01:00:00' );
alert( t.getTimezoneOffset() )
will I see the offset for that date (which may or may not include an
adjustment for daylight saving), or for when the code is run?
It should be for that date, by current rules.
It seems to me it *should* return the offset for that particular date,
including daylight saving if known to be in force at that time. The
ECMAScript Language specification doesn't really help here.
I thought it clear (ISO 16262 15.9.1.8). The Summer Time Rules which
are currently valid should be applied for all dates past present and
future, even if the OS could do "better". You've noticed the ECMA3 bug
there?
AFAIK, Vista is the first non-UNIX OS, or at least the first Windows, to
store more than one set of date rules for a locality.
If you've been following the US legislative situation, you'll know that
the new US rules came into force on 2007-03-01. The legislation
mentioned no time, so I suppose they mean at 00:00h local time.
Therefore, Vista users in most of North America should have been able to
see the value of +new Date("31 March 2007") change by 36e5 at the
stroke of local midnight starting March 2007; and law-abiding US users
of Windows and javascript should have installed their DST update at that
instant in order to be able to do the same.
Opera 9.21 has a Summer Time bug for some dates before 1970 and from
2038, when run in UK. It should be tried in CA and AU.
function X99() { var YY, Y, M, D, DOb, A
A = ["Try exact dates in 11-year ranges; IE & FF are OK.\n" +
"Opera 9.21 shows me errors near most Summer Time steps" +
" except 1970-2037."]
for (YY=1970 ; YY<2050 ; YY+=68) { A.push("")
for (Y=YY-4 ; Y<YY+5 ; Y++) for (M=0 ; M<12 ; M++)
for (D=0 ; D<32 ; D++) { DOb = new Date(Y, M, D)
if (DOb.getHours()!=0) A.push(LZ(D) + " " + DOb) }
}
document.write(A.length>3 ? A.join("\n") : A[0] ) }
