search

jalexiscv / base2

Automatically exported from code.google.com/p/base2
0 stars 0 forks source link

JSON.Date.toString as UTC #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Now JSON.Date.toString returns a string in the format "yyyy-MM-ddThh:mm:ss", 
same as on the 
www.json.org site. 

The enhancement is to render the string in UTC timezone ("time zone less"), 
including milliseconds: 
"yyyy-MM-ddThh:mm:ss:milZ".

Before checking in, I'd like your opinion.

Original issue reported on code.google.com by doek...@gmail.com on 11 Jul 2007 at 1:41

Attachments:

GoogleCodeExporter commented 9 years ago 
Three questions:

1. Why is this better?
2. Does it add much code?
3. Is it a good idea to parse JSON differently than other libraries?

Original comment by dean.edw...@gmail.com on 11 Jul 2007 at 2:12

GoogleCodeExporter commented 9 years ago 
1. Why is this better?
No information is thrown away. Now milliseconds, timezone offset and 
daylightsavings offset are thrown 
away. When creating a time zone-spanning website, that is accounted for. 

2. Does it add much code?
Not much as you can see in the attached file (one extra function [pad3] and one 
extra line). I use 
getUTCFullYear instead of getFullYear,  and so on for other date-parts. 
According to http://
developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date,
 the all are introduced in 
javascript 1.3 (so I don't need to do calculations).

I don't include timezone information in the date, although it's possible. I 
think, this information is part of 
locale-settings.

3. Is it a good idea to parse JSON differently than other libraries?
We're not parsing differently. A Date is serialized to a string. When read back 
again, the string is still a string. 
And when parsed, the string can always be truncated.

Original comment by doek...@gmail.com on 11 Jul 2007 at 5:16

GoogleCodeExporter commented 9 years ago 
You make a good case but I'd rather stay in synch with the official JSON spec. 
This
is supposed to be a standards-based library after all.

Original comment by dean.edw...@gmail.com on 13 Jul 2007 at 6:00

Attachments:

GoogleCodeExporter commented 9 years ago 
I agree. We're adding support when Douglas Crockford changes his library, 
Firefox implements it, Ecmascript 
4 is published or it appears in the Ecmascript 4 reference implementation. 
Right?

In the mean time, i'll put my implementation in utils.

Besides, my implementation wasn't complete. The toISO proposal says the string 
should be as short as 
possible (omit time information from the right when it's zero). Also, it's not 
clear on in what timezone it 
should be serialized.

Links:
http://www.json.org/js.html
https://bugzilla.mozilla.org/show_bug.cgi?id=340987
http://developer.mozilla.org/es4/proposals/json_encoding_and_decoding.html
http://developer.mozilla.org/es4/proposals/date_and_time.html#iso_date_strings
http://www.ecmascript-lang.org/

Original comment by doek...@gmail.com on 13 Jul 2007 at 7:32

GoogleCodeExporter commented 9 years ago 
I've put the support in utils/Xstra/Date2.js as a Module. 
JSON.Date.toString can refer to .toISO for the serialization.

Original comment by doek...@gmail.com on 14 Jul 2007 at 4:53

GoogleCodeExporter commented 9 years ago

Original comment by doek...@gmail.com on 14 Jul 2007 at 7:27

GoogleCodeExporter commented 9 years ago 
Closing issue, awaiting standards.

Original comment by doek...@gmail.com on 14 Jul 2007 at 7:31