I can't help it. :-)
There seems to be a dilemma in regards to consistency of dates:
Compare the first parargaph of http://www.json.org:
"JSON (_javascript_ Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the _javascript_ Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, _javascript_, Perl, Python, and many others. These properties make JSON an ideal data-interchange language."
with http://www.json.org/js.html:
"JSON is a subset of the object literal notation of _javascript_. Since JSON is a subset of _javascript_, it can be used in the language with no muss or fuss. [...] To convert a JSON text into an object, use the eval() function. eval() invokes the _javascript_ compiler. Since JSON is a proper subset of _javascript_, the compiler will correctly parse the text and produce an object structure."
Which is more important?
By the way, the JSON Parser on http://www.json.org/json.js will return {} if you toJSONString() a date. So will MochiKits serializeJSON(). So no one else seems to have made a decision on that yet, either. And yes, if JSON needs to stay a subset of _javascript_, this needs to be addressed in the language itself.
a) If you want to stick to the second paragraph (note how that one says "is" instead of "is based on" a subset of _javascript_), you might as well use _javascript_'s ugly string representation, which provides a roundtrip (and timezone info):
var d = new Date()
var string_from_date = d.toString()
var date_from_string = new Date(string_from_date)
Then the server would need to be able to parse something like "new Date('Fri Jun 16 2006 15:53:27 GMT+1200 (NZST)').
The problem here is it doesn't have milliseconds.
And of course the problems with the first paragraph: any server side language would need to do some string slicing before parsing the relevant parts - the "new" is especially confusing. And who cares about the weekday, or a three letter month name?
b) What's wrong with ISO8601 in both directions?
Bob Ippolito - whose MochiKit aims to "make Javascrip suck less" - says in some recent slides ( http://svn.mochikit.com/presentations/2006/ajax_experience/slides.html ): "_javascript_ Data objects aren't very convenient. W3C profile ISO8601 style timestamps are Good." - I agree.
So okay, you don't want to introduce an "@" or whatever but rather have something that you can eval() directly, as the second paragraph "requires". Fair enough. But why this weird format?
Qooxdoo applications could use two simple functions for converting back and forth between Date objects and proper ISO timestamps, like in MochiKit's DateTime.js. That would sort the client side. "JS built-in stuff only" is obviously not a requirement!
On the server side "isoTimestamp('2006-06-16T03:53:27Z')" (yes the client can eval this - through qooxdoo), is at least as easy to parse as "new Date(Date.UTC(2006,6,16,3,53,27))". I left out milliseconds here.
But what I don't get at all is how you are going to construct the string "new Date(Date.UTC(2006,6,16,3,53,27))" on the client side? Firstly, your date needs to be UTC to begin with, and you will need to split the components up. So you will need helper functions anyway.
Basically what I want to say is, qooxdoo is on the client, _javascript_ is obviously not running on the server, so why not eval() an established standard like ISO8601 with qooxdoo?
Date objects seem to be treated like "user-defined" objects, so another perfectly valid option would be to store this ISO representation "as-is" and class hint to "isoTimestamp" or whatever you wanna call it.
If you are going to re-invent the wheel then please the other one. :-)
Cheers,
--
Danny W. Adair
Director
Unfold Limited
New Zealand
Talk: +64 4 472 1679
Fax: +64 4 472 1680
Write: [EMAIL PROTECTED]
Browse: www.unfold.co.nz
Visit/Post: 22a Clifton Terrace, Kelburn 6005, Wellington, New Zealand
==============================
Caution
The contents of this email and any attachments contain information which is CONFIDENTIAL and may be subject to LEGAL PRIVILEGE. If you are not the intended recipient, you must not read, use, distribute, copy or retain this email or its attachments. If you have received this email in error, please notify us immediately by return email or collect telephone call and delete this email. Thank you. We do not accept any responsibility for any changes made to this email or any attachment after transmission from us.
==============================
_______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
