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 > -- Oetiker+Partner AG tel: +41 62 775 9903 (direct) Fritz Zaucker +41 62 775 9900 (switch board) Aarweg 15 +41 79 675 0630 (mobile) CH-4600 Olten fax: +41 62 775 9905 Schweiz web: www.oetiker.ch ------------------------------------------------------------------------------ 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
