Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON.Date.toString as UTC #22

Closed
GoogleCodeExporter opened this issue Jun 26, 2015 · 7 comments
Closed

JSON.Date.toString as UTC #22

GoogleCodeExporter opened this issue Jun 26, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Added labels: Browser-All, Module-base2.JSON

@GoogleCodeExporter
Copy link
Author

Closing issue, awaiting standards.

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

  • Changed state: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant