Re: time and again

From: James Rogers (jimmaureenrogers_at_att.net)
Date: 12/25/03 

Date: Thu, 25 Dec 2003 14:58:27 GMT

"Martijn" <subscription-removethis-101@hot-removethis-mail.com> wrote in
news:3feab0cf$0$328$e4fe514c@news.xs4all.nl:

>> One consideration might be the approach to time taken by Unix boxes.
>> The processor marks time based upon UTC.
>
> Does that imply that every date "exists" and that the difference from
> UTC changes? This would make life a bit easier, but still the
> potential for the off-by-one-hour issue :) But I think it may indeed
> simplify the problem somewhat. Is there a platform independant method
> of acquiring this difference?

Yes. UTC does not deal with Summer time changes. It does need to deal
with leap years.

A platform independent method would involve converting all dates to
a count of the number of seconds since some epoch date. Unix boxes
traditionally use January 1, 1976 as their epoch date. If your
scheduler is only going forward in time from today I would suggest
January 1, 2001 as a good epoch date. This avoids calculations starting
with a leap year. (2000 was a leap year).

Each time zone applied against your time standard needs to specify its
local offset from UTC. If the time zone uses Summer time changes you must
specify the Summer time offset as well as the local date and time of
each change.

This approach allows you to handle additional oddities of time keeping.
For instance, most time zones are a whole number of hours offset from
UTC. Some are a combination of hours and fractional hours offset.

>
>> but that is a bounded problem with a well published
>> algorithm.
>
> Can anybody point me in the direction of such an algorithm? Or does
> anybody have a hint on what search terms I could use? Until now I
> haven't had any luck with Google.
>

You might visit comp.protocols.time.ntp. The people in that group are
well versed in time computation details.

Jim Rogers

Relevant Pages

  • Re: Question about ISO8601 vs. strftime()
    ... online references to ISO8601 just get it wrong? ... that link only shows the form with the UTC ... but not the offset as far as I can tell. ... assumed to be in some local time zone. ...
    (comp.programming)
  • Re: Davis Weatherlink export problem
    ... It sticks with UTC and TZ offset. ... One could say that Davis are American and therefore the rest of the ... I've just reset the time zone to Hobart and it works fine. ...
    (uk.sci.weather)
  • Re: Strategies for time offsets
    ... There isn't a mechanism for a negative delta time within the quadword storage, though applications are certainly free to stuff a sign bit somewhere. ... The UTC format is often a better choice here, particularly when dealing with the storage of time values. ... And then, in the core of the program, I would simply need to do a LIB$ADD_TIMES and not have to worry about whether the offset is negative or positive. ... Barring cases where this timezone stuff is the bulk of the operation and there's nothing else around consuming more cycles or wallclock time -- I/O tends to be my go-to example here for massive overhead -- I'd tend to look to optimize this math stuff and any associated system call overhead later. ...
    (comp.os.vms)
  • Re: Windows 2000 forest time synch
    ... Internally Windows uses UTC, time zone ... offset is applied just for visualization purposes so you shouldn't have ...
    (microsoft.public.win2000.active_directory)
  • Re: obtaining the time offset from UTC
    ... >> I need to find out the time difference between UTC and local time. ... >> saving and always returns local time zone offset. ... >> When daylight saving is not in effect, then the offset should be +1 hour. ...
    (comp.lang.c)