Hi, Am 14.06.2006 um 04:36 schrieb [EMAIL PROTECTED]:
> 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. Thanks :-) I admit it looks a bit scary/hackish. > "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. I see. IMHO, this is not a good solution then. > 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. Only if you work in the 32-bit space. JavaScript has no problem handling dates like "new Date(-4150281915000)" (which is June 26th 1838). I'm not sure if PHP can work with such early dates, but in general, a server environment that supports date operations based on seconds since the epoch should be able to handle such dates (either as 64 bit values, double float values, structs, etc.). > If possible, we should support, at > least at the transport level even if the server doesn't support it, > a much > broader date range. See above, the range at the transport level should already be broad enough. If the server environment cannot parse large numbers, you can also parse them as groups of 3 or something and make the necessary calculations afterwards. > We also need to have the ability to support time zone, I > think. JavaScript is your friend :-) The current RPC code uses the Date (<number>) constructor and getTime() for the reverse operation (getting the number of milliseconds since the epoch). Both operations are defined as working in UTC in the JavaScript reference. The JavaScript date class supports operations to get UTC or local date components from a Date object as well as getting the local timezone offset. I think working in UTC on the wire is better than adding additional timezone information. > 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. The current format is milliseconds since the epoch (since this is what the Date() constructor accepts and what getTime() returns), so the precision is already there. If PHP can't handle it, just parse the first digits and ignore the last 3 (so you get seconds instead of milliseconds) - it's a simple substring operation. If you want to be more precise and perform some rounding, you can also look at the first of the last 3 digits and check if it's >= 5. > 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. We could also use a date string as <something> (JavaScript understands a variety of these). However, it's harder to deal with this on the server-side. Correct me if I'm wrong, but I think all server environments that support dates can work with seconds since the epoch, while you don't have good routines for parsing date strings everywhere. It wouldn't be a problem for Java though (don't know about PHP). Regards, Andreas -- Dipl.-Inform.(FH), M.Sc. Andreas Junghans STZ-IDA an der Hochschule Karlsruhe email [EMAIL PROTECTED] internet http://stz-ida.de telefon ++49-721-920-3302 fax ++49-721-160-890-56 Moltkestrasse 30, D-76133 Karlsruhe/Germany _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
