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

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

At Mon, 26 Jan 2004 12:51:16 -0800, "David L. Oppenheimer" <dav...@cs...> wrote:
> I was assuming the value could have two separate pieces (as in the timeval).
> There are advantages and disadvantages to doing this compared to (for
> example) a single floating point number.

Not least ambiguity - while it's well-specified, I've seen a number
of programmer errors where people have assumed that 123456.1 refers to
either 123456.1 seconds, OR 123456.000001 seconds, OR
123456.000000000001 seconds, depending on the format, and got it
wrong. 

I'm in favour of human-readable representations, but only if there's a
nice standard.  If we're going to break a standard, or such things
don't exist, then I vote for a single floating point value represented
in ASCII as the number of seconds from the epoch. 

This also happens to be Python's default representation.  

 -- Mothy
> 
> > -----Original Message-----
> > From: pla...@li...
> > [mailto:pla...@li...] On Behalf
> > Of David L. Oppenheimer
> > Sent: Monday, January 26, 2004 12:41 PM
> > To: 'Steve Muir'
> > Cc: pla...@li...
> > Subject: RE: [Planetlab-arch] Proposed Changes for Dynamic Slice API
> >
> > How about just using number of microseconds for subsecond
> > resolution, as is
> > done in the Unix timeval struct?
> >
> > David
> >
> > > -----Original Message-----
> > > From: pla...@li...
> > > [mailto:pla...@li...] On Behalf
> > > Of Steve Muir
> > > Sent: Monday, January 26, 2004 12:35 PM
> > > To: Timothy Roscoe
> > > Cc: pla...@li...
> > > Subject: Re: [Planetlab-arch] Proposed Changes for Dynamic Slice API
> > >
> > > 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
> 
> 
>