extend date-time format to allow time zone offset

[Ben Hockey]

currently, the json-schema spec describes date-time format as:

YYYY-MM-DDThh:mm:ssZ in UTC time.  

 

es5[1] is a little more loose and describes "Z" as 

the time zone offset specified as “Z” (for UTC) or either “+” or “-” followed by a time expression hh:mm

i was wondering if there would be support for changing the description for date-time format to allow for this format.  i realize that the json-schema spec doesn't prevent a validator from allowing this format but the wording of the spec does act as a guide to anyone implementing a validator and influencing validators to support this format would be beneficial in my opinion.  

my goal is to try and make it simpler to use some of the default formats available from databases.  in my particular case, postgres has (is adding?) support for an "XSD" datestyle that matches the format described by es5 except that the implementation produces "+00:00" rather than "Z" for UTC.  also, it takes some extra effort to coerce the database to return the result to UTC - by default it uses the local timezone (i guess the machine's timezone or something).  anyhow, i'm just trying to show that my request is driven by practicality more than anything else.

thanks,

ben...

[1] http://es5.github.com/#x15.9.1.15 (this link is not the official reference but allows me to link directly to the section)

[Hagen]

On Wed, Dec 7, 2011 at 5:07 PM, Ben Hockey <neonst...@gmail.com> wrote:

currently, the json-schema spec describes date-time format as:

YYYY-MM-DDThh:mm:ssZ in UTC time.  

 

es5[1] is a little more loose and describes "Z" as 

the time zone offset specified as “Z” (for UTC) or either “+” or “-” followed by a time expression hh:mm

i was wondering if there would be support for changing the description for date-time format to allow for this format.

I think that's a bad idea.

With dates fixed to "Z" you can string compare them for chronological order (ok, that is Y10k bug waiting to happen, but still). Once you allow anything but "Z" that's out of the window and you have to parse them for comparison.

[Joe Littlejohn]

> With dates fixed to "Z" you can string compare them for chronological order
> (ok, that is Y10k bug waiting to happen, but still). Once you allow anything
> but "Z" that's out of the window and you have to parse them for comparison.
>

Hagen, I think this is a very weak reason to omit timezones from the spec.

I'd support this addition wholeheartedly and I agree that the wording
of the spec should be changed here to guide implementers in the right
direction. Omitting time-zone offsets might seem like a simplification
but it's likely to make life unnecessarily difficult for those that
need to represent a variety of date-time values in different
time-zones. Z is a useful shortcut, but offsets of the form +/hh:mm
are essential.

The simplified ISO 8601 representation described in es5 looks perfect.

[Bob Aman]

I would add that there are certain use-cases where preserving the
localized offset is useful, like calendaring APIs. Forcing UTC is not
always desirable, even if it is the right thing to do 90% of the time.

[Paul C. Bryan]

My vote would be yes, align with the ECMA 262 5.1 specification and allow ±hh:mm.

Paul

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To view this discussion on the web visit https://groups.google.com/d/msg/json-schema/-/kfbuaEywA18J.
To post to this group, send email to json-...@googlegroups.com.
To unsubscribe from this group, send email to json-schema...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.