Hi Gene, On Tue, 1 Dec 2009, Gene Amtower wrote:
> 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 just wanted to point out that there are other (to me more important) areas where Epoch is relevant. > 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. Welcome. I had the advantage of just being able to search for "Epoch time" and then the Wikipedia link is rather prominent ... ;-) Cheers, Fritz > 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 >>> >> > -- 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
