Opera 9 Summer Time Errors

[Dr J R Stockton]

Computed at <URL:http://www.merlyn.demon.co.uk/js-datex.htm#OST> by the
code shown above it when using Opera 9.24 :


Test exact dates in two 11-year ranges; IE & FF are OK.
Opera 9.24 shows errors near most/all EU Summer Time steps
outside 1970-2037.

1966-03-27 -> Sat, 26 Mar 1966 23:00:00 GMT+0000
1966-10-28 -> Thu, 27 Oct 1966 23:00:00 GMT+0000
1967-03-30 -> Wed, 29 Mar 1967 23:00:00 GMT+0000
1967-10-27 -> Thu, 26 Oct 1967 23:00:00 GMT+0000
1968-10-31 -> Wed, 30 Oct 1968 23:00:00 GMT+0000
1969-10-31 -> Thu, 30 Oct 1969 23:00:00 GMT+0000

2038-03-31 -> Tue, 30 Mar 2038 23:00:00 GMT+0000
2038-10-29 -> Thu, 28 Oct 2038 23:00:00 GMT+0000
2039-03-27 -> Sat, 26 Mar 2039 23:00:00 GMT+0000
2039-10-28 -> Thu, 27 Oct 2039 23:00:00 GMT+0000
2040-03-29 -> Wed, 28 Mar 2040 23:00:00 GMT+0000
2041-03-29 -> Thu, 28 Mar 2041 23:00:00 GMT+0000
2042-10-31 -> Thu, 30 Oct 2042 23:00:00 GMT+0000


Lines containing -> show new Date(Y, M, D).toString() for the date which
starts the line. All dates in those years are tested.


It would be interesting to see what happens
in parts of the EU not currently using GMT/UTC,
in Russia,
in North America (with DST),
upside-down (e.g. Australia, where Summer <-> Winter),
in Lord Howe Island,
where there are no seasonal clock changes,
in engines other than those of IE, FF, Opera.


Note : that error may not fully explain all I've seen; but it's enough
to show that Opera is weird with some date object operations where
seconds-from-1970.0 is either negative or exceeds signed 32-bit. Can
they be using the integer bitwise operations or other 32-bit code
internally?


<URL:http://www.merlyn.demon.co.uk/weekcalc.htm> has failures on Opera
9, probably related.


Is anyone here connected with the Opera composers? It needs fixing.
Bug report sent.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Tue, 18 Dec 2007 13:42:49, Dr J R Stockton

Computed at <URL:http://www.merlyn.demon.co.uk/js-datex.htm#OST> by the
code shown above it when using Opera 9.24 :

It would be interesting to see what happens
in parts of the EU not currently using GMT/UTC,
in Russia,
in North America (with DST),
upside-down (e.g. Australia, where Summer <-> Winter),
in Lord Howe Island,
where there are no seasonal clock changes,
in engines other than those of IE, FF, Opera.

Isn't there anyone here in a position to try that?

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Mon, 24 Dec 2007 13:52:38, Dr J R Stockton

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Tue, 18 Dec 2007 13:42:49, Dr J R Stockton


Isn't there anyone here in a position to try that?

Someone did; thanks, David. No fault shown in the US EST area.

While I am not prepared to fiddle with the clock settings of this
machine, which routinely runs stuff that might be adversely affected, it
eventually occurred to me that I do have access to a machine running
Opera 9.25 without that limitation.

So I've tried all those places, and some others, except for Lord Howe
Island - it's a market that Windows XP seems to ignore - and have found
the effect ONLY with UK-type settings.

Therefore I now particularly ask for confirmation or refutation from the
"Dublin, Edinburgh, Lisbon, London" area, lest there be some peculiarity
in my machines.


Of course, my "UK new Date(Y,M,D) observation suggests that Opera 9.25
contains 32-bit signed seconds arithmetic; the fact that the same wrong
results have not been seen for other locations is no guarantee that
other use of the Opera Date Object elsewhere will not go wrong for that
reason.

In fact, new Date(Date.UTC(2038, 2, 28))
Opera 9.25 Sun, 28 Mar 2038 01:00:00 GMT+0100
IE 6 Sun Mar 28 00:00:00 UTC 2038
but for 2010, 28 years earlier and therefore matching, they both give
what should be given in the UK. That's a .toString() error; although
the derails of the string are not defined in detail, they should
represent the Real World. That one seems to be EU-wide. Confirm?

 

[Thomas 'PointedEars' Lahn]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Tue, 18 Dec 2007 13:42:49, Dr J R Stockton

Computed at <URL:http://www.merlyn.demon.co.uk/js-datex.htm#OST> by the
code shown above it when using Opera 9.24 :
[...]
It would be interesting to see what happens
in parts of the EU not currently using GMT/UTC,
in Russia,
in North America (with DST),
upside-down (e.g. Australia, where Summer <-> Winter),
in Lord Howe Island,
where there are no seasonal clock changes,
in engines other than those of IE, FF, Opera.

Isn't there anyone here in a position to try that?

First, most people were/are on holidays; I had it on my to-do list. Second,
you might have gotten more responses if you had provided a test case instead
of letting people created their own. Opera isn't the easiest browser to
test with; there is an error console but there is no way to ad-hoc execute
code but with `javascript:' in the address bar. Fortunately, Firebug's
console's Copy feature allowed me to convert your slightly adapted code with
a single click to:

javascript: document.open(); (function X99() { var YY, Y, M, D, DOb, A;
A = ["Your GMT Offsets in minutes :" + " Jan : " + (new Date(2008, 0,
1)).getTimezoneOffset() + " Jul : " + (new Date(2008, 6,
1)).getTimezoneOffset() + "\nTesting exact dates in two 9-year ranges; IE &
FF are OK." + "\nOpera 9.25 gives me errors near most EU Summer Time" +
"\nsteps outside 1970-2037. All following lines show errors."]; 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 = 1; D < 32; D++) { DOb = new Date(Y, M, D);
if (DOb.getMonth() != M) { continue;
} if (DOb.getHours() != 0) {
A.push(Y + "-" + LZ(M + 1) + "-" + LZ(D) + " -> " + DOb);
} } } } }
document.write("<pre>" + (A.length > 3 ? A.join("\n") : A[0]) + "</pre>");
})(); document.close();

FWIW, here's the result for my Opera/9.24 (Windows NT 5.1; U; en):

| Your GMT Offsets in minutes : Jan : -60 Jul : -120
| Testing exact dates in two 9-year ranges; IE & FF are OK.
| Opera 9.25 gives me errors near most EU Summer Time
| steps outside 1970-2037. All following lines show errors.

(complete output)


HTH

PointedEars

 

[Dr J R Stockton]

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

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Tue, 18 Dec 2007 13:42:49, Dr J R Stockton

Computed at <URL:http://www.merlyn.demon.co.uk/js-datex.htm#OST> by the
code shown above it when using Opera 9.24 :
[...]
It would be interesting to see what happens
in parts of the EU not currently using GMT/UTC,
in Russia,
in North America (with DST),
upside-down (e.g. Australia, where Summer <-> Winter),
in Lord Howe Island,
where there are no seasonal clock changes,
in engines other than those of IE, FF, Opera.

Isn't there anyone here in a position to try that?

First, most people were/are on holidays; I had it on my to-do list. Second,
you might have gotten more responses if you had provided a test case instead
of letting people created their own.

I am not interested in sorting out what other code does. It is only
necessary to report what my page says.

Opera isn't the easiest browser to
test with; there is an error console but there is no way to ad-hoc execute
code but with `javascript:' in the address bar. Fortunately, Firebug's
console's Copy feature allowed me to convert your slightly adapted code with
a single click to:

javascript: document.open(); (function X99() { var YY, Y, M, D, DOb, A;
A = ["Your GMT Offsets in minutes :" + " Jan : " + (new Date(2008, 0,
1)).getTimezoneOffset() + " Jul : " + (new Date(2008, 6,
1)).getTimezoneOffset() + "\nTesting exact dates in two 9-year ranges; IE &
FF are OK." + "\nOpera 9.25 gives me errors near most EU Summer Time" +
"\nsteps outside 1970-2037. All following lines show errors."]; 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 = 1; D < 32; D++) { DOb = new Date(Y, M, D);
if (DOb.getMonth() != M) { continue;
} if (DOb.getHours() != 0) {
A.push(Y + "-" + LZ(M + 1) + "-" + LZ(D) + " -> " + DOb);
} } } } }
document.write("<pre>" + (A.length > 3 ? A.join("\n") : A[0]) + "</pre>");
})(); document.close();

FWIW, here's the result for my Opera/9.24 (Windows NT 5.1; U; en):

Ignored; I'm not going to bother with that appallingly-presented code,
which may or may not be a faithful copy. Your Opera is out-of-date.

By the way, lack of a DSN is no proof of receipt.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Sun, 30 Dec 2007 21:04:40, Dr J R Stockton

In fact, new Date(Date.UTC(2038, 2, 28))
Opera 9.25 Sun, 28 Mar 2038 01:00:00 GMT+0100
IE 6 Sun Mar 28 00:00:00 UTC 2038
but for 2010, 28 years earlier and therefore matching, they both give
what should be given in the UK. That's a .toString() error; although
the derails of the string are not defined in detail, they should
represent the Real World. That one seems to be EU-wide. Confirm?

Well, although it is an error in .toString(), it seems to be an error
caused either by .toString calling defective .getTimezoneOffset or by
both calling some internal defective routine.

The prime cause of the error shown above is not necessarily identical to
the prime cause of the aforementioned new Date(Y,M,D) error, since the
former seems EU-wide but the latter affects only GB & PT.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Mon, 31 Dec 2007 19:48:43, Dr J R Stockton

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Sun, 30 Dec 2007 21:04:40, Dr J R Stockton



Well, although it is an error in .toString(), it seems to be an error
caused either by .toString calling defective .getTimezoneOffset or by
both calling some internal defective routine.

The prime cause of the error shown above is not necessarily identical to
the prime cause of the aforementioned new Date(Y,M,D) error, since the
former seems EU-wide but the latter affects only GB & PT.

I am pleased to report that a new test in <URL:http://www.merlyn.demon.
co.uk/js-datex.htm> also shows Opera errors when set to New York time -
function X66 under heading "List Offset Changes", press "Changes"
button. IE, FF are OK.


In that, stepping ms by 864e5 from years 1960 to 2065 usually shows,
outside 1968-2037, four or six clock changes per year.

Sydney 2038 shows 8 changes; likewise Wellington.