Thanks, Fritz...
On Tue, 2009-12-01 at 17:56 +0100, Fritz Zaucker wrote:
> 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 agree with you on this point. Actually, I would be fine with either
of these two options for JSON date representations, as both of them
appear to be more common that the way it's currently implemented in
Qooxdoo. I do, however, like the readability of the ISO-8601 format. I
can do a lot of math in my head, but calculating dates from millisecond
values is NOT one of my mental talents. ;-)
Thanks again,
Gene
>
> > 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
> >>>
> >>
> >
>
------------------------------------------------------------------------------
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
