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

[Aaron K. <al...@CS...>]

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