"Danny Adair" <[EMAIL PROTECTED]> writes:
> 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.
> b) What's wrong with ISO8601 in both directions?
The problem other than lack of milliseconds (which I consider a requirement)
is that the server would have to generate different date strings depending on
what browser it's talking to. Unfortunately, the javascript standard doesn't
dictate the string that should be generated by d.toString() or what
Date.parse() should accept. The only requirement is that a browser
implementation be able to parse the date that its own toString() generates.
There is absolutely no guarantee that the IETF format you've shown will be
supported by browsers, so the server would have to know what format a
particular browser supports, and send that format. Yuck.
> 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.
> 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.
> Basically what I want to say is, qooxdoo is on the client, Javascript is
> obviously not running on the server,
Sorry, that's not so obvious. :-) I expect we'll be using these features in
Samba. Samba (v4) has built-in javascript and a web server, so in fact, the
server *is* running javascript. (That said, I'm not sure that we'd natively
eval() any arbitrary junk coming from a browser. More likely, we'll parse it
to ensure we're not receiving anything dangerous.)
> so why not eval() an established standard like ISO8601 with qooxdoo?
That's what I tried. It doesn't work in Firefox. If you can convince me that
calling a locally-generated isoTimestamp() function is better than calling
Date object creation functions, I'm willing to reconsider.
> 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.
It is very unfortunate that Date objects are treated like "user-defined"
objects, since they are in fact a native object. The reason they're treated
as "user-defined" is because there is no literal syntax for them. Once there
is a literal syntax and it is well-supported, I expect we'll support receiving
the literal syntax instead of this "new Date()" stuff.
> If you are going to re-invent the wheel then please the other one. :-)
I think we're trying to re-invent as little as possible, while still making it
work properly and efficiently, and be as easy as possible for various servers
to implement it. There will be two examples (Java and PHP), and I can easily
envision how I'd implement a C version.
Cheers,
Derrell
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
