Re: [Planetlab-arch] Proposed Changes for Dynamic Slice API

[Timothy R. <tr...@in...>]

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
> >
> 
> 
>