Created attachment 238924 [details]
for example in bug137244
attachment date: 2014-09-30 06:16 PST --> 15:16 in CEST (GMT+2)
But the style checker (and the others too) bubble says it finished
the patch at 13:18:18 GMT+2, 2 hours before submitting the patch.
I ran into this bug with latest Firefox, but the time seems
to be valid with Safari and Chrome.
The problem is that the time is converted to local time
with this JS code: new Date("2014-09-30T13:18:18.902015").toString()
But the trailing "Z" or "+00:00" is missing to indicate that the time
is in UTC/GMT. Can we add "Z" to the datetime string somehow?
ECMA 262 stated clearly in "18.104.22.168 Date Time String Format" the following:
The value of an absent time zone offset is “Z”.
So it is an ugly bug in FF and IE too. :-/
But why not add the trailing "Z" if we can make the bad boys happy too.
(In reply to comment #2)
> ECMA 262 stated clearly in "22.214.171.124 Date Time String Format" the following:
> The value of an absent time zone offset is “Z”.
> So it is an ugly bug in FF and IE too. :-/
> But why not add the trailing "Z" if we can make the bad boys happy too.
But the ES6 will change the behaviour: "If the time zone offset is absent, the date-time is interpreted as a local time."
So +1 to use "Z", because this time is in UTC and it will work with ES5 and ES6 too.
Created attachment 238926 [details]
Comment on attachment 238926 [details]
Looks like this is not the most pythonic way to fix this - the right one is to use pytz package and replace(tzinfo=simple_utc()). But this is simpler and faster, so why not.
Please make the same change in queuestatusjson.py before landing. Ping me when landed, so that I could deploy.
Ossy, will you have a chance to look into this further?
Created attachment 239336 [details]
Patch for landing
Comment on attachment 239336 [details]
Patch for landing
Clearing flags on attachment: 239336
Committed r174343: <http://trac.webkit.org/changeset/174343>
All reviewed patches have been landed. Closing bug.