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
