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

[Steve M. <sm...@CS...>]

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
>