Re: a clock in it, was Re: Interesting News Article

[Howard Brazee]

On Tue, 26 Jun 2012 06:01:25 -0400, jack...@bright.net wrote:

>I've been lucky enough not to be on duty during any daylight savings
>time shift, because I don't know how the bosses would react to the log
>entries I would be compelled to make:
>
>01:59 Entering time warp
>01:01 Exiting time warp

That can be expensive in data processing. I've worked with time
sensitive databases that took a couple of hours to adjust 1 hour, so
that sequencing did not change.

They never should have been stored with local time stamps anyway. Zulu
works better.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison

[David DeLaney]

Howard Brazee <how...@brazee.net> wrote:
>They never should have been stored with local time stamps anyway. Zulu
>works better.

Compleat with speares to shake?

Dave "i compute only the happy outcomes" DeLaney
--
\/David DeLaney posting from d...@vic.com "It's not the pot that grows the flower
It's not the clock that slows the hour The definition's plain for anyone to see
Love is all it takes to make a family" - R&P. VISUALIZE HAPPYNET VRbeable<BLINK>
http://www.vic.com/~dbd/ - net.legends FAQ & Magic / I WUV you in all CAPS! --K.

[Niklas Karlsson]

On 2012-06-26, Howard Brazee <how...@brazee.net> wrote:
> On Tue, 26 Jun 2012 06:01:25 -0400, jack...@bright.net wrote:
>
>>I've been lucky enough not to be on duty during any daylight savings
>>time shift, because I don't know how the bosses would react to the log
>>entries I would be compelled to make:
>>
>>01:59 Entering time warp
>>01:01 Exiting time warp
>
> That can be expensive in data processing. I've worked with time
> sensitive databases that took a couple of hours to adjust 1 hour, so
> that sequencing did not change.
>
> They never should have been stored with local time stamps anyway. Zulu
> works better.

I've been bitten by this going both ways.

I was an operator at a small stock/securities exchange for a while.
Expected to follow local hours, open at 9 am and close at 5:30 pm. But
the hours for the various states the markets could be in were stored in
Zulu, so we had to go in and tweak the state transition timers by two
hours in the database twice a year. (Needless to say this could've been
handled automatically, but that was never a development priority during
my time there...)

Then, another transaction-intensive system, but open 24/7 to people in
various time zones. This one stored events in local time, so we had
planned downtime around the DST changes. The stated scenario they were
afraid of was two events ending up with identical timestamps, which
would have unpredictable effects. Of course, that doesn't explain why the
system also had to be down when the clock moved forward, but the orders
were clear, even after we tried to reason with their originators...

So in short, I guess this is a design decision that requires careful
thought. Much like many others.

Niklas
--
if (!this->with_sin())
(int) stones[0];
-- Joe Pfeiffer's friend

[Ahem A Rivet's Shot]

On 11 Jul 2012 19:21:11 GMT

Niklas Karlsson <ank...@yahoo.se> wrote:

> On 2012-06-26, Howard Brazee <how...@brazee.net> wrote:
> > On Tue, 26 Jun 2012 06:01:25 -0400, jack...@bright.net wrote:
> >
> >>I've been lucky enough not to be on duty during any daylight savings
> >>time shift, because I don't know how the bosses would react to the log
> >>entries I would be compelled to make:
> >>
> >>01:59 Entering time warp
> >>01:01 Exiting time warp
> >
> > That can be expensive in data processing. I've worked with time
> > sensitive databases that took a couple of hours to adjust 1 hour, so
> > that sequencing did not change.
> >
> > They never should have been stored with local time stamps anyway. Zulu
> > works better.
>
> I've been bitten by this going both ways.

The easiest way to handle it IME is to do all internal processing
of dates and times using integer timestamps, either the unix style 32 bit
count of seconds past an epoch or better the more recent java style 64 bit
count of milliseconds past an epoch. The only time they get translated is
for user interface and that respects the timezone of the user.

Anything else is fraught with serious problems - even storing the
time and timezone together can lead to errors unless you have a complete and
*correct* record of DST change dates as well as any leaps applied for *all*
timezones over the period of interest - and even if you have all the data
it's going to be a PITA making sure it's *always* processed correctly. At
least using integer timestamps the internal storage is sure to be sane even
if there are presentation errors caused by inaccurate timezone rules data.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[Joe Morris]

On 2012-06-26, Howard Brazee <how...@brazee.net> wrote:
> On Tue, 26 Jun 2012 06:01:25 -0400, jack...@bright.net wrote:

>>I've been lucky enough not to be on duty during any daylight savings
>>time shift, because I don't know how the bosses would react to the log
>>entries I would be compelled to make:

>>01:59 Entering time warp
>>01:01 Exiting time warp

> That can be expensive in data processing. I've worked with time
> sensitive databases that took a couple of hours to adjust 1 hour, so
> that sequencing did not change.

> They never should have been stored with local time stamps anyway. Zulu
> works better.

*IF* you can be absolutely certain which logs show Zulu and which show
local. More than once I've had to argue with network and/or server types
when they send me a log with no indications of what time base is being used,
or, if it's local time, whether or not the recorded times reflect DST, and
the events recorded are sufficiently different that it's effectively
impossible to try all the combinations and look for equialent entries in two
logs.

Joe

Joe