Right, and there are differences between browser dealing with time zones.
On Sat, Nov 20, 2010 at 8:59 PM, P T Withington <[email protected]> wrote:
> You're seeing the difference between ES3 Date and ES5 Date. ES5 specifies
> that passing a string to the Date constructor tries to parse the string as an
> ISO-format date first.
>
> I suppose we could make it consistent(ly bad) by specifying ES3 as the
> Javascript version of OL code.
>
> Or we could use a trick similar to what André did for RegExp support in swf8:
> trampoline these calls out to the browser. But then, you would be at the
> mercy of the browser's Date implementation.
>
> Other ideas? I guess you should file a bug.
>
> On 2010-11-20, at 14:12, Raju Bitter wrote:
>
>> Are you aware of the difference in Date implementation for HTML5 and
>> AS3 based runtimes?
>>
>> HTML5:
>> new Date(2010).toString() 'Thu Jan 01 1970 01:00:02 GMT+0100'
>> new Date("2010").toString() 'Fri Jan 01 2010 00:00:00 GMT+0100'
>>
>> SWF10:
>> new Date(2010).toString() 'Thu Jan 1 01:00:02 GMT+0100 1970'
>> new Date("2010").toString() 'Invalid Date'
>>
>> But then check the values for for Chrome, Rhino and Opera:
>> Chrome V8 (in Chrome browser)
>> new Date(2010).toString() "Thu Jan 01 1970 01:00:02 GMT+0100 (CET)"
>> new Date("2010").toString() "Fri Jan 01 2010 00:00:00 GMT+0100 (CET)"
>>
>> Rhino JS engine:
>> new Date(2010).toString() Thu Jan 01 1970 01:00:02 GMT+0100 (CET)
>> new Date("2010").toString() Invalid Date
>>
>> Opera Dragonfly:
>> new Date(2010).toString() "Thu Jan 01 1970 01:00:02 GMT+0100"
>> new Date("2010").toString() "Fri Jan 01 2010 00:00:00 GMT+0100"
>
>
