Andreas Junghans <[EMAIL PROTECTED]> writes: > OK, enough rambling :-) I don't mean to bash your solution, and you have > good points. I just want to make it clear where I'm coming from and what my > concerns are.
And a fine job of it you're doing! You're not bashing my solution; rather, you're offering reasoned debate. I think I now understand exactly where you're coming from and the justification for and implementation of "new Date()". I think I'm becoming convinced that this is a better way to go than what I was proposing, and not as much of a bastardization as I had thought. "Danny Adair" <[EMAIL PROTECTED]> adds additional fuel to the fire: > There seem to be two issues: > 1. How to "tag" data to indicate it's a date > 2. Deciding on the string format which represents the date > > ad 1.: > Dates seem to be such a common type of data that they deserve "special > treatment" as part of the standard, but they're not getting it. It's my > understanding that this is underway. > Obviously, as long as there is no standard in JSON, you would need to invent > something with the risk of becoming incompatible later. Have a look at these > thoughts: http://www.nikhilk.net/DateSyntaxForJSON.aspx This is a good reference. As opposed to the reference's title ("Date Literal Syntax for JSON"), what he is really proposing (and has submitted) is a change to javascript itself. Once those changes are in javascript, then, e.g. eval(@2006/06/13@) will yield a Date object with the appropriate date, and the speed enhancement of being able to eval() the JSON result are realized. Unfortunately, those changes are not in javascript (yet, at least), so using this syntax requires the extra pass through the eval()'ed data that I'm doing in my implementation (or manual parsing in javascript rather than using eval()), which negates Andreas' desired speed enhancement. Even the article's author states in one of the comments towards the end that his implementation uses "new Date()" for now since javascript does not provide a literal syntax for Date. Danny brings up a number of additional points that should be handled by the implementation. Although the date range of "seconds since the beginning of the epoch" actually begins around 1900 because the seconds value can be negative, it is still a limited range. If possible, we should support, at least at the transport level even if the server doesn't support it, a much broader date range. We also need to have the ability to support time zone, I think. I'm a bit concerned about how to deal with sub-second (e.g. millisecond) precision. I'm not sure that all languages can deal with them (e.g. PHP), but I think they really should be available in the protocol. RFC3339 formats do allow for them. I will play with this some more over the coming days. I'll look into parsing "new Date(<something>)" in the PHP server, and will experiment with various <something>s. I'm still eager for additional comments, but at least for now, I have a research direction. Thanks Andreas and Danny! Others with comments, please chime in. Derrell _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
