opera Bugs

[Dr J R Stockton]

Opera 10 has fixed the error in (0.5).toFixed(0) : its toFixed used to
do Bankers Rounding.

But the Summer Time error which I thought was cured between versions
9.61 & 9.64 has reappeared in 10.00 AND 9.64. I now suspect that it
depends on whether it is currently Summer at the test location. What
happens in Australia, if it is still Winter Time there?

For details, see <URL:http://www.merlyn.demon.co.uk/js-datex.htm>.

Also, Opera may be getting the background colour of the "Opera Summer
Time" section wrong.

 

[Evertjan.]

Dr J R Stockton wrote on 20 sep 2009 in comp.lang.javascript:

But the Summer Time error which I thought was cured between versions
9.61 & 9.64 has reappeared in 10.00 AND 9.64. I now suspect that it
depends on whether it is currently Summer at the test location. What
happens in Australia, if it is still Winter Time there?

Again another example of "better do this serverside".

 

[Dr J R Stockton]

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

Dr J R Stockton wrote on 20 sep 2009 in comp.lang.javascript:


Again another example of "better do this serverside".

If there is an active serverside, and if its internals can be relied
upon. Perhaps someone here is in a position to code that test, and
distribute it so that it can be run on various servers.

The Opera error does not occur for years for which the seconds count is
positive and less than 2^31, which rather suggests an ill-conceived
simplistic approach.

: : :

I want to perform Date.UTC(1e99) in all browsers, without invoking
any conspicuous indication of error. For example, it is OK to write
into an existing debug window, but not to open one. All was well until
Opera 10. Any suggestions?

 

[Evertjan.]

Dr J R Stockton wrote on 20 sep 2009 in comp.lang.javascript:

Again another example of "better do this serverside".

If there is an active serverside, and if its internals can be relied
upon. Perhaps someone here is in a position to code that test, and
distribute it so that it can be run on various servers.
[..]

I want to perform Date.UTC(1e99)

Perhaps this can help you,
the result does not mean anything to me:

========== test.asp ==========
<script language='javascript' runat='server'>
Response.write(Date.UTC(1e99));
</script>
<p>
<script type='text/javascript'>
document.write(Date.UTC(1e99));
</script>
==============================

returns in Google Chrome:

3.1556952E+109

NaN

 

[Dr J R Stockton]

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

Dr J R Stockton wrote on 20 sep 2009 in comp.lang.javascript:

Again another example of "better do this serverside".

If there is an active serverside, and if its internals can be relied
upon. Perhaps someone here is in a position to code that test, and
distribute it so that it can be run on various servers.
[..]

I want to perform Date.UTC(1e99)

Perhaps this can help you,
the result does not mean anything to me:

========== test.asp ==========
<script language='javascript' runat='server'>
Response.write(Date.UTC(1e99));
</script>
<p>
<script type='text/javascript'>
document.write(Date.UTC(1e99));
</script>
==============================

returns in Google Chrome:

3.1556952E+109

NaN

Indeed. For 3.1556952E+109 = 1e99 * 365.2425 * 864e5, and you will
recognise those factors. As the date range of JavaScript is only
1970.0 GMT +- 1E8 days, both results are reasonable. Change 1e99 to
2009, and both tests should give the same answer.

But, as I indicated, the problem is only in Opera 10, which gives an
intolerable conspicuous indication of error. A way of dealing with
Opera 10 must be acceptable to other browsers.

 

[Thomas 'PointedEars' Lahn]

[...]
But, as I indicated, the problem is only in Opera 10, which gives an
intolerable conspicuous indication of error. A way of dealing with
Opera 10 must be acceptable to other browsers.

<http://www.opera.com/browser/next/> ;-)


SCNR

PointedEars

 

[Evertjan.]

Dr J R Stockton wrote on 21 sep 2009 in comp.lang.javascript:

Indeed. For 3.1556952E+109 = 1e99 * 365.2425 * 864e5, and you will
recognise those factors. As the date range of JavaScript is only
1970.0 GMT +- 1E8 days, both results are reasonable. Change 1e99 to
2009, and both tests should give the same answer.

Nice! Did not think of that.

But, as I indicated, the problem is only in Opera 10, which gives an
intolerable conspicuous indication of error. A way of dealing with
Opera 10 must be acceptable to other browsers.

So serverside javascript coding will result in an acceptable Opera 10
result, circumventing the bug. ;-)

 

[Dr J R Stockton]

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

So serverside javascript coding will result in an acceptable Opera 10
result, circumventing the bug. ;-)

No, for two reasons. I don't do server-side; and the entire purpose is
to test client-side.

 

[Evertjan.]

Dr J R Stockton wrote on 23 sep 2009 in comp.lang.javascript:

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


No, for two reasons. I don't do server-side;

I cannot argue that.

and the entire purpose is to test client-side.

No, if that were the only purpose, then the testing would be futile.

Testing is only sensible if you plan do something with the result.
In my view that most often is trying to write useful code.
[sometimes it is just for fun, or to fill a faq, both also very legitimate]

Since we in this NG cannot change Opera's bug overnight,
it is sensible to look for altenative code.
Serverside code is very crossbrowser resilient by it's nature.

So I would advise programmers that have this problem with Opera to use
serverside code.

 

[Dr J R Stockton]

REPOST :

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

and the entire purpose is to test client-side.

No, if that were the only purpose, then the testing would be futile.

Testing is only sensible if you plan do something with the result.
In my view that most often is trying to write useful code.
[sometimes it is just for fun, or to fill a faq, both also very legitimate]

So you need not worry about that.

Since we in this NG cannot change Opera's bug overnight,

It's not a bug. ECMA does not specify behaviour in this case. It is a
difference. Date.UTC(1e+99) is something that a naive IE user might
employ, and a test shows, in a satisfactory manner, the strange result
that one browser gave and the reasonable result that most others give.
Feature testing will handle those differences. Opera, however, is too
ostentatious, and I would like to replace the work-round of browser
detection to suppress the test.

So I would advise programmers that have this problem with Opera to use
serverside code.

No need; they can use alternative client-side code.

 

[Evertjan.]

Dr J R Stockton wrote on 26 sep 2009 in comp.lang.javascript:

No need; they can use alternative client-side code

This works both ways:

No need for alternative client-side code,
since they can use serverside code.

Using serverside code is the most easily testable way for
cross-browser-proof-ness.

I think newbies should be aware of this escape route,
next to the other advantages of serverside coding.

Then again using also alternative client-side code
also has it's intelectual charme.

 

[Dr J R Stockton]

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

This works both ways:

But none of that helps with :

I want to perform Date.UTC(1e99) in all browsers, without invoking
any conspicuous indication of error. For example, it is OK to write
into an existing debug window, but not to open one. All was well until
Opera 10. Any suggestions?

<FAQENTRY> How about having in the FAQ a list of bug-reporting URLs for
major browsers?

 

[Evertjan.]

Dr J R Stockton wrote on 27 sep 2009 in comp.lang.javascript:

In comp.lang.javascript message <Xns9C93A93852B82eejj99@ 194.109.133.242>

But none of that helps with :

I want to perform Date.UTC(1e99) in all browsers, without invoking
any conspicuous indication of error. For example, it is OK to write
into an existing debug window, but not to open one. All was well until
Opera 10. Any suggestions?

I am not an Opera fan since my Windows Mobile was put aside for the much
more stable Andriod OS, so I am not current on all the modus operandi
inside number 10.

The whole idea, however of Javascript using the local time as a default,
and the UTC as a special case with seperate functions is asking for
trouble.

Why not start with:

new Date() or
new Date(aDate) or
new Date(aDate,'local') or
new Date(aDate,+1) // West European summertime

and

new Date(,'UTC') or
new Date(aDate,'UTC') or
new Date(aDate,0)

and expanding the date object from there?

This could be prototyped by us, allowing for backward compatibility,
till the powers that be see the light and incorporate it into standards
and new Versions().

Bug circumvention could be incorporated as an added bonus.

<FAQENTRY> How about having in the FAQ a list of bug-reporting URLs for
major browsers?

I would try to report cross-browser compatibility for each function,
and perhaps point to acceptable circumvention code.

Perhaps as part of your website?

 

[Dr J R Stockton]

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

Dr J R Stockton wrote on 27 sep 2009 in comp.lang.javascript:


I am not an Opera fan since my Windows Mobile was put aside for the much
more stable Andriod OS, so I am not current on all the modus operandi
inside number 10.

The whole idea, however of Javascript using the local time as a default,
and the UTC as a special case with seperate functions is asking for
trouble.

That is such a good idea that I did it some while ago. See
<URL:http://www.merlyn.demon.co.uk/js-dobj2.htm>. It has no known bugs;
but I'd not be altogether surprised to hear of something to fix in the
code.

Apart from FFF support, Julian Calendar & Orthodox Easter, have I left
anything out?

Why not start with:

new Date() or
new Date(aDate) or
new Date(aDate,'local') or
new Date(aDate,+1) // West European summertime

and

new Date(,'UTC') or
new Date(aDate,'UTC') or
new Date(aDate,0)

and expanding the date object from there?

I think it better to have a "global" DATE2.GMT, default false.

Then (for example) setMonth uses GMT or Local Civil Time (LCT)
accordingly. That would be easy for browsers to implement; existing
setMonth must necessarily consult the system to find the Winter Offset &
Summer Time situation, and there would just be a preliminary test of
DATE2.GMT to use constant zero offset if true. Pure GMT work would be
insignificantly slower, because of that test.

String "GMT" is better than "UTC" as JavaScript has no Leap Seconds;
"UT" would be better, but is too like "UTC".

Adding extra arguments leads to the possibility of forgetting to do so.

Almost any code not using "new DATE2()", or using it just for timing
intervals, should be run with DATE2.GMT set to true, for speed.

This could be prototyped by us, allowing for backward compatibility,
till the powers that be see the light and incorporate it into standards
and new Versions().

Mentioned in my <URL:http://www.merlyn.demon.co.uk/js-262-5.htm>, which
was made known to TPTB as a response to request for comment in ECMA-262
Final Draft 5. A response has indicated that at least one relevant
person has paid it some attention; and at least one point therein has
been attended to in a later draft.

Why is the Final Draft not the last one?

I dropped source-code compatibility in favour of replacing "UTC" and
corresponding "" in method names with "X". That's trivial to learn, and
prevents unthinkingly using old Methods; but perhaps unnecessary in a
new native Object.

Bug circumvention could be incorporated as an added bonus.

Perhaps. Between 9.20 & 10, Opera introduced at least one Date Object
bug, dropping compatibility with 262-3 for compatibility with IE.
<URL:http://www.merlyn.demon.co.uk/js-datex.htm> refers.

Try <http://www.bbc.co.uk/programmes/b007jwdh> <G>