I had a look around, and everyone (including the examples on json.org) elegantly omits Date objects in JSON. :-)
Various workarounds exist, and JSON-_RPC_ class hinting seems to be favored.
My vote goes for a __jsonclass__ constructor "QXDate". Hopefully some more people will participate in this discussion.
Andreas, I remember you were concerned about client-side overhead. You're only saving the evaluation, not the creation.
Kind regards,
Danny
On 6/19/06,
Danny Adair <[EMAIL PROTECTED]> wrote:
Hello Derrell,On 6/17/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:[...]
> 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.
If one has to have a function call in there, I'm not convinced that calling
our own function, isoTimestamp() is any better than calling new Date(). In
fact, I'd venture that the latter will at least be recognized by _javascript_
programmers who are writing a new JSON server (in whatever language), and
they'll know what to do with it. The latter also sticks much more closely
with the JSON concept, in that only native _javascript_ is included.
see below> 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?
Trivial. The Date methods give you everything you need. I had that working
already. Take a look at the various methods available with the Date object.
> 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.
The date needn't be UTC to begin with. The Date methods let you create the
Date object as localtime and retrieve the date as UTC, and vice versa, and
they also provide the methods to produce the individual date components.Kind regards,
Sorry, I think there's a misunderstanding.
Of course you can construct "new Date(Date.UTC(2006,6,16,3,53,27))" but you will use a (qooxdoo) helper function to do this, in _javascript_ something like
return 'new Date(Date.UTC(' + d.getUTCFullYear() + ',' + d.getUTCMonth() + ',' + d.getUTCDate() + ',' + d.getUTCHours() + ',' + d.getUTCMinutes() + ',' + d.getUTCSeconds() + ',' + d.getUTCMilliseconds() + '))'
(Btw, why would you not allow spaces when this is still valid _javascript_?)
Here, you could have gone for an ISO8601 timestamp function instead, which is what I want to argue for:
Where is the original timezone? It's gone; it's not available to the server anymore. Even worse, wherever you JS-eval() that string the local timezone will be attached! Just compare
new Date(Date.UTC(2006,5,19,5,7,6,182))
with
new Date(Date.UTC(2006,5,19,5,7,6,182)).toUTCString()
in a _javascript_ console. If you create a new date using milliseconds since 1970 UTC, your new Date will get your local timezone, which is possibly different to where it was created.
On the server side, where you not only need to parse these kind of (let's say _javascript_-proprietary) strings but also construct them, you're introducing a new convention: Must be UTC. You need to start off with a UTC date and then construct from the different parts. I think this is an unnecessary requirement.
http://mochikit.com/doc/html/MochiKit/DateTime.html
"Remote servers don't give you _javascript_ Date objects, and they certainly don't want them from you, so you need to deal with string representations of dates and timestamps. MochiKit.Date does that."
ISO8601 is a standard which is either part of a language (or its standard library) or there is a library in the language - including _javascript_ - that does the job for you. Qooxdoo could use/include one of them. If you are really running _javascript_ on the server side (voluntarily?), copying the 2-function-library from qooxdoo to your server will be just as easy as writing a converter for above weird format in _every language other than _javascript__.
Servers will need to parse these dates - qooxdoo needs to parse these dates.
Servers will thank you for ISO8601 - qooxdoo will use a helper function (to construct them) anyway.
There is no JSON standard for dates - You're not defining one, this is qooxdoo.
I therefore think that something like "qxDate(<ISOdatestring>)" would be fine.
What do you think of storing the iso timestamp and class hint "ISO8601", "qxDate" or similar name?Danny
--
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.
==============================
--
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
