Fritz,
LOL! I wasn't suggesting Microsoft invented this approach (or the
Internet for that matter) - only that they had adopted this approach.
It's rare for Microsoft to invent anything, they just adopt and extend
at will. I appreciate your clarification, though.
Anyway, thanks for the additional links to wikipedia. I didn't think to
look there and it didn't show up at the top of my google searches - it
should have been a prominent search result.
The javascript code in [2] from json.org provides the means to both
generate and detect/parse the ISO-8601 format, although I didn't read
through the js code from end to end.
Thanks,
Gene
On Tue, 2009-12-01 at 16:58 +0100, Fritz Zaucker wrote:
> Hmm,
>
> neither the Internet nor the Epoch notation were invented my Microsoft ...
>
> Not a first hand source, but http://en.wikipedia.org/wiki/Unix_time gives
> some more information.
>
> http://en.wikipedia.org/wiki/ISO_8601 has a discussion of this standard
> which has the advantage compared to Epoch notation, that leap seconds are
> handled correctly (they cannot be represented in Epoch it seems).
>
> On the other hand, Epoch makes it a lot easier to do date/time calculations.
>
> Cheers,
> Fritz
>
> On Tue, 1 Dec 2009, Gene Amtower wrote:
>
> > Team,
> >
> > I've been researching the JSON Date problem a bit, and I wanted to share
> > some information from my web research. Since I'm working on an Oracle
> > RPC backend, I'd like to design and develop it once, so I'd prefer to
> > sort this out before doing the heavy lifting in my development.
> >
> > It is clear to all that the JSON standard does not offer a standard
> > method for dealing with dates, beyond the fact that they are to be
> > represented as a string in whatever form the developer chooses. This
> > leaves developers with a myriad of choices for handling JSON dates.
> > IMHO, Qooxdoo developers have chosen a string format that is uniquely
> > different than anyone else's chosen format, likely chosen before any
> > established practices began to surface in the industry. So, no fault is
> > intended towards the Qooxdoo development team. However, I wonder if
> > it's time to consider using a more common approach to JSON dates in
> > order to align with other development environments, although I recognize
> > that it may have downsides to Qooxdoo developers, especially WRT
> > backwards compatibility.
> >
> > I've come up with the following resources that you may want to review,
> > with related links provided at the end...
> >
> > On the json.org website, I found a lengthy PowerPoint presentation [1]
> > on the JSON standard that includes mention of new proposed extensions
> > for generating JSON data structures near the end (slide 40 of 55
> > slides). It references a js file containing proposed javascript code
> > [2] to extend various javascript prototypes in order to generate
> > standard JSON structures. Of course, one of these is the Date
> > prototype, and it might offer the Qooxdoo team a suitable pseudo-
> > standard since it comes directly from the JSON.org team.
> >
> > In addition, I found a really great discussion [3] while googling the
> > topic, which talks about two of the most common methods for encoding
> > dates in JSON structures. While one method is based on epoch time in
> > milliseconds since January 1st, 1970 UTC, I think many dislike it
> > because it's not human-readable. (Most of us would be hard-pressed to
> > be able to read milliseconds and readily relate them to a specific
> > date/time value!) This appears to be the method preferred by
> > VisualStudio and .Net tools. The other method mentioned is based on the
> > W3C ISO-8601 standard [4], which calls for date/time values in a
> > standard string representation of varying granularity such as
> > "1997-07-16", "1997-07-16T19:20+01:00", and "1997-07-16T19:20:30.45
> > +01:00", depending on the precision requirements of the usage. This is
> > much more human-readable and comes directly from the W3C standards body,
> > offering a more solid foundation for a choice in Qooxdoo direction.
> >
> > The prototype extension code contained in the json.org js file [2] is
> > based on this ISO-8601 standard, suggesting to me that this would be the
> > preferred approach despite its convergence away from the Microsoft
> > approach. (Is that so bad?)
> >
> > It's my opinion that any changes implemented in the Qooxdoo RPC methods
> > as a result of ongoing discussions should attempt to align Qooxdoo's
> > date-handling with a pseudo-standard in the industry. Keeping the
> > current implementation as a non-standard alternative (selected through a
> > class-level or project-level flag) would be OK for those who need it.
> > Additional comments and discussions would likely be beneficial to
> > Qooxdoo's future.
> >
> > Hope this is more helpful than disruptive! I welcome your thoughts on
> > the topic.
> >
> > Thanks,
> >
> > Gene
> >
> > [1] http://www.json.org/xml2006.ppt
> > [2] http://json.org/json.js
> > [3] http://weblogs.asp.net/bleroy/archive/2008/01/18/dates-and-json.aspx
> > [4] http://www.w3.org/TR/NOTE-datetime
> >
> > On Tue, 2009-12-01 at 02:01 -0800, panyasan wrote:
> >
> >> Hi Derrell,
> >>
> >>
> >> Derrell Lipman wrote:
> >>>
> >>> I just added the following to the jsonrpc_extensions wiki pgae:
> >>>
> >>> qooxdoo JSON dates
> >>>
> >>> Traditionally, qooxdoo JSON-RPC backends have been required to support a
> >>> non-standard feature of JSON, passing Date object instances as
> >>> instantiations of a Date object using syntax like new
> >>> Date(Date.UTC(2009,11,29,3,10,23,973)) since dates are not a part of the
> >>> JSON specification. This proposal moves qooxdoo Dates into the realm of
> >>> ?extension? rather than required functionality.
> >>>
> >>>
> >>
> >> I think this is a good idea, because supporting JSON Dates makes generating
> >> the json more complicated and not every application needs this
> >> functionality
> >> (I don't, for example). So servers might not implement this at all or offer
> >> a way of turning JSON dates "on" and "off". Maybe you might want to add a
> >> "system.useJsonDates(boolean v)" system method to your proposal?
> >>
> >> Cheers,
> >>
> >> Christian
> >
>
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
