Re: [Planetlab-arch] Proposed Changes for Dynamic Slice API
Brought to you by:
alklinga
Menu
▾
▴
Re: [Planetlab-arch] Proposed Changes for Dynamic Slice API
|
From: Timothy R. <tr...@in...> - 2004-01-27 17:44:22
|
So Google is your friend: http://www.w3.org/TR/NOTE-datetime defines a date format as a particular instance of ISO8601. Various subsets are allowed, but the full monty looks like: 2004-01-27T09:38:03.456-08:00 The timezone can instead by 'Z' (for UTC/GMT/Zulu). This is (reasonably) human readable, includes a precise notion of time zone, and allows a decimal fraction for seconds. It also avoids the problem of specifying the accuracy of the timestamp (microseconds? nanoseconds?) since it's just a fraction. Finally, it's a well-known XML standard (xsd:dateTime): http://books.xmlschemata/org/relaxng/ch17-77031.html I vote for this. It's also easy to parse into a time_t. -- Mothy At Mon, 26 Jan 2004 13:27:06 -0800, Timothy Roscoe <tr...@in...> wrote: > > Hang on a moment. > > Since we're already using XML-RPC (presumably because IIOP is too > standardized, XDR is too easy, and and ASN.1/BER is too compact), > SURELY the Web Services people have standardized an accurate date > format? > > Is there a web services expert on this list? Feel free to post > anonymously if you want to keep quiet about it. > > -- Mothy > > > At Mon, 26 Jan 2004 16:11:52 -0500 (EST), Steve Muir <sm...@CS...> > wrote: > > in what sense is it harder to debug? since the functions for manipulating > > epoch-relative values are all part of the standard C library i would > > expect them to be well debugged already. and why is this well-defined > > value less portable than some string for which we have to point people to > > a complex spec. for example, do you know how many spaces go between the > > month and date strings if the date string is only a single digit? > > > > yes, there will be programmer error when 123.456 gets interpreted as 456 > > microsecs, but there will also be a ton of programmers who get their > > regexps wrong when, say, the date or hour is a single digit. > > > > i'm assuming that there will always be a program between the output of the > > API and the end user (isn't that why it's called the programmatic API?), > > so i'd rather make it easy for the program to parse the input and use > > existing functions to output a value in whatever the format the user > > wants. if you have to output anything other than UTC values you're going > > to be converting to an internal epoch-relative value anyway. > > > > steve > > > > > > > > On Mon, 26 Jan 2004, Aaron Klingaman wrote: > > > > > You may be right about that, but my instinct tells me not to use a > > timestamp > > > like that. Harder to debug, a bit less portable than a generic string. > > It'll > > > cost a bit more to parse and ensure the timestamp is correct, but I think > > > it'd be worth it in the long run. > > > > > > Aaron > > > > > > On Monday 26 January 2004 03:47 pm, Steve Muir wrote: > > > > i don't think it makes using the API any more difficult on non-UNIX > > boxes. > > > > python, and i imagine perl and most other scripting languages, can > > > > manipulate epoch-relative values directly, as can any C program (the > > ctime > > > > function and its relatives are part of C89). or am i missing > something? > > > > > > > > steve > > > > > > > > On Mon, 26 Jan 2004, Aaron Klingaman wrote: > > > > > How much more difficult will it make using the api on non-linux type > > > > > machines, like a windows box? > > > > > > > > > > I would vote for a more readable string. > > > > > > > > > > ak > > > > > > > > > > On Monday 26 January 2004 03:35 pm, Steve Muir wrote: > > > > > > yes, i meant exactly what you wrote. i wrote 'UTC epoch' since i > > > > > > wasn't sure if the definition of Unix epoch specified that it was > > > > > > relative to UTC. > > > > > > > > > > > > we could presumably support sub-second resolution using floating > > point > > > > > > numbers (or fixed point if there are accuracy issues with floating > > > > > > point), but i haven't thought through whether that has > complications. > > > > > > > > > > > > i agree that this makes it less straightforward to check timestamps > > > > > > visually, but on the other hand i expect that it will eliminate a > > bunch > > > > > > of parsing errors; parsing an integer/float is much more 'uniform' > > than > > > > > > parsing a string like "Mon Jan 26 15:32:46 UTC 2004" in the sense > > that > > > > > > i don't have to deal with special cases like single-digit values. > > > > > > > > > > > > steve > > > > > > > > > > > > On Mon, 26 Jan 2004, Timothy Roscoe wrote: > > > > > > > At Mon, 26 Jan 2004 15:06:18 -0500 (EST), Steve Muir > > > > > > > > > > <sm...@CS...> wrote: > > > > > > > > how about seconds since UTC epoch? it's easiest to parse and > > meets > > > > > > > > all of your requirements. > > > > > > > > > > > > > > > > steve > > > > > > > > > > > > > > I don't think there is a UTC epoch. But I'm assuming you mean > the > > > > > > > Unix epoch, which is "seconds since 00:00:00 UTC, January 1, > 1970". > > > > > > > That works for me too, but is harder to debug. > > > > > > > > > > > > > > -- Mothy > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > > > > Premiere Conference on Open Tools Development and Integration > > > > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > > > > http://www.eclipsecon.org/osdn > > > > > > > _______________________________________________ > > > > > > > Planetlab-arch mailing list > > > > > > > Pla...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/planetlab-arch > > > > > > > > > > > > ------------------------------------------------------- > > > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > > > Premiere Conference on Open Tools Development and Integration > > > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > > > http://www.eclipsecon.org/osdn > > > > > > _______________________________________________ > > > > > > Planetlab-arch mailing list > > > > > > Pla...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/planetlab-arch > > > > > > > > ------------------------------------------------------- > > > > The SF.Net email is sponsored by EclipseCon 2004 > > > > Premiere Conference on Open Tools Development and Integration > > > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > > > http://www.eclipsecon.org/osdn > > > > _______________________________________________ > > > > Planetlab-arch mailing list > > > > Pla...@li... > > > > https://lists.sourceforge.net/lists/listinfo/planetlab-arch > > > > > > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Planetlab-arch mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/planetlab-arch > > > |
