[PATCH] Unambiguous Time, Date and DateTime #to_json format

Any reason not to go all the way to RFC-3339? A lot of people spent a lot of, um, time thinking about these issues. And the -00:00 offset (which I hadn't heard of till now) could prove useful, given Rails' out-of-the-box time-zone-agnosticism.

Replying to jaylev:

Any reason not to go all the way to RFC-3339? A lot of people spent a lot of, um, time thinking about these issues. And the -00:00 offset (which I hadn't heard of till now) could prove useful, given Rails' out-of-the-box time-zone-agnosticism.

This standard won't work, unfortunately, if we wish to output dates that are compatible with the peculiarities of Javascript's Date.parse() function, which can't parse dates separated by '-' (you need to use '/').

When Time, Date and DateTime #to_json were first added, Date.parse compatibility was considered, see #8399 for the discussion.

I'd like to see this as well and checked that Firefox does parse the date string in "2007/10/01 12:15:02 CDT" format correctly (using new Date("2007/10/01 12:15:02 CDT")).

We will need to look around to see whether the "2007/10/01 12:15:02 CDT" is a universally parseable date string in the different browsers (or whether there is any "standard" format). I dug around and can't find much yet but I'll report back when I do.

Setup a test page here. Basically just runs new Date(date_string_from_rails) with the date string format that this patch would output.

Works for me in Firefox 2 (Windows and Mac), Safari 2 and 3 (Mac), IE6, IE7, Firefox 3.0a9pre (Mac), and Opera 9.50. I believe it's a good format that new Date(date_string) and Date.parse() would parse correctly. If someone has some older or more obscure browsers please help verify the times are parsed correct!

Replying to chuyeow:

Setup a test page here. Basically just runs new Date(date_string_from_rails) with the date string format that this patch would output.

Thanks for putting this test page up -- very helpful. Works for me in all the browsers I have access to (nothing outside of the ones you listed.)

I suppose to be thorough, we should also test the format outputted by DateTime.to_json, which displays the zone as "+00:00" instead of "UTC".

Regarding if there's a standard format -- the ECMA-262 spec isn't specific on which formats Date.parse should recognize:

"...in general, the value produced by Date.parse is implementation-dependent when given any string value that could not be produced in that implementation by the toString or toUTCString method." (15.9.4.2)

The output of toString is "implementation-dependent" as well:

"The contents of the string are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient , human-readable form." (15.9.5.2).

  1) Failure:
test_datetime(TestJSONEncoding)
    [./test/json/encoding_test.rb:39:in `test_datetime'
     ./test/json/encoding_test.rb:38:in `each'
     ./test/json/encoding_test.rb:38:in `test_datetime'
     /usr/local/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in `__send__'
     /usr/local/lib/ruby/gems/1.8/gems/mocha-0.5.5/lib/mocha/test_case_adapter.rb:19:in `run']:
<"\"2005/02/01 15:15:10 +00:00\""> expected but was
<"\"2005/02/01 15:15:10 Z\"">.

(see %z vs %Z format strings)

Replying to bitsweat:

(see %z vs %Z format strings)

Hmm this actually works for me (can't get that test to fail).

But I'm aware of the tricky platform-specific issues regarding the %z and %Z format string.

Time#strftime and DateTime#strftime produce different outputs for %Z. Time tries to give it a timezone (e.g. UTC, CDT), whereas DateTime outputs it in +00:00 or +0000.

Using %z is slightly better since both Time and DateTime gives +0000 (no colons). But I've read that it is platform-dependent.

I think the most ideal way for to_json output is to be consistent for Time and DateTime (same format), and they should be of the form:

2007/10/01 12:15:02 +0800

I've tested this form in the same browsers listed above and new Date(date_string) parses correctly (take note the lack of a colon). 3-letter TZ codes don't work in Opera but this +HHMM format does.

Anyway, if anyone has any suggestions on how to approach this please do. I'm leaning towards forcibly outputting +HHMM instead of using the platform-dependent strftime.

Time#to_json and DateTime#to_json is encoded the same way

I've added another patch (keeping to gbuesing's YYYY/mm/dd format) that makes Time#to_json and DateTime#to_json consistent (basically, Times are first converted to DateTimes).

Changed strftime format string to

"%Y/%m/%d %H:%M:%S %z"

I've found that this converts on Mac OS X and Windows XP to +HHMM format (e.g. +0000, +0800). I've tested this format using JavaScript's new Date(date_string) in: Firefox 2 (Windows and Mac), Safari 2 and 3 (Mac), IE6, IE7, Firefox 3.0a9pre (Mac), and Opera 9.50 using this test page.

Needs more testing across different platforms (esp. Linux) and browsers.

I've added another patch (keeping to gbuesing's YYYY/mm/dd format) that makes Time#to_json and DateTime#to_json consistent (basically, Times are first converted to DateTimes).

Good idea, that will ensure consistency between Times and DateTimes, and hopefully across platforms.

On Debian Etch:

>> DateTime.civil(2000).strftime("%Y/%m/%d %H:%M:%S %z")
=> "2000/01/01 00:00:00 +0000"

+! Tests confirmed...

+1

(In [7746]) Disambiguate Time, Date, and DateTime#to_json formatting. Closes #9750.

(In [8636]) Time#to_json uses Numeric#to_utc_offset_s to output cross-platform-consistent representation without having to convert to DateTime. References #9750