On Tue, Dec 1, 2009 at 10:35, Gene Amtower <[email protected]> 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.
>
The format used for JSON dates by qooxdoo was selected for one specific
reason: it is fast for the client side to parse dates back into Date
objects. Any other format requires deciding (at some point, either while
parsing, or by the user's application) that the string or numeric value is
in fact supposed to be a date, and doing a conversion. The format we use is
FUGLY. We've always known that, and Andreas Junghans and I debated this for
a LONG time many years ago, trying to find a solution that yielded both a
conformant JSON string AND a format that yielded a Date object if what was
sent by the server was intended as a date. The JSON spec used to (and may
still) have a mechanism for providing type hints. Both Andreas and I felt it
was too inefficient.
Without special date processing, there is no way to pass a date from the
server to the client and have a Date object created automatically. Therein
lies the big problem. JavaScript neglected to include a literal form for the
Date object. It is the ONLY native object for which no literal form exists.
This is the root of the problem. Any of these other formats being discussed,
ISO8601 or milliseconds since the epoch, will end up at the client as a
string in the former case, or a number in the latter case... not as a Date
object which is really what's desired. The user application will have to
convert it.
I still feel strongly that it should be possible to pass a Date in JSON. I
really wish they'd fix JavaScript to have a Date literal form, and then JSON
would likely quickly follow with an update allowing that form. That ain't
gonna happen any time soon, and as much as I think we should continue to
support native Dates, I think moving it to the realm of "extension" is
appropriate. As an extension, the qooxdoo Date format can remain. *Any other
Date format, too, will have to be an extension.* Dates just can't be sent
natively in JSON without special processing, so a special format must be by
agreement between client and server... or the client and server should just
do no special processing. In that case, dates will be passed as a number or
as a string, and only converted to a date by user code (at each end) that
knows that the string or number actually represents a date.
Derrell
------------------------------------------------------------------------------
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
