4

Does anybody know if there is a possibility to switch from summer- to wintertime without an interruption in the timeline. I have an application that logs transactions with a timestamp. The problem is, that I must not have overlapping timestamps. If I simply switch the clock from 3am to 2am i have an overlapping. Means that I can have two times the time 2:30 for example.

But if the time started to run twice as slow at 2 pm, I would have the correct time at 3pm without an interruption and without a broken timeline.

So does anybody know if there is a protocol that supports this? NTP does not seem to do that. And there is no chance to change the application, the last time we just stopped it for one hour, but there must be something better.

Improve this question

3 Answers 3

Reset to default
19

I would log everything in UTC (Coordinated Universal Time), this way daylight saving is never observed. It is the common default time setting for Linux servers.

You can then present both the UTC and the local timezone time at the application layer.

Reading about the tzdata package might be of interest to you.

From that Wikipedia article:

UTC does not change with a change of seasons, but local time or civil time may change if a time zone jurisdiction observes daylight saving time or summer time. For example, UTC is 5 hours ahead of local time on the east coast of the United States during the winter but 4 hours ahead during the summer.

Improve this answer
1
  • Oh, and as far as coding the reverse goes if you have to. I would parse the log files with perl. You could just use a regex, and then create datetime objects with them (see cpan). A regex might be something like: my $timeStampRegex = '(?<year>\d\d\d\d)-(?<month>\d\d)-(?<mday>\d\d) (?<hour>\d\ d):(?<minute>\d\d):(?<sec>\d\d)';
    – Kyle Brandt
    Oct 27, 2009 at 19:03
6

No, there is no way to do this. Local time simply overlaps, there's nothing you can do about it. You could of course use some kind of sliding changeover during the DST changes, but that would further complicat things (e.g. timestamps during the changeover would be rather weird).

The easiest solution (probably the only solution) is to use UTC for logging timestamps. You can always convert the times to whatever local time you like when displaying them.

Improve this answer
0
5

I agree with Kyle Brandt that logging in UTC is best. If that is not acceptable (and neither is having events happening an hour apart recorded with the 'same time'), then report the time zone offset (as well as, or instead of, the time zone name) in the log, so that you see:

2009-11-01 01:59:59 -07:00 ...event 1...
2009-11-01 01:00:00 -08:00 ...event 2...one second after event 1...

This gives the complete information for those who need it; but it is fairly easily ignorable for those who don't. The implied time zone above is 'US/Pacific' (or the preferred name, America/Los_Angeles) and is the correct time zone switch for 2009.

The date format shown is a minor variant on the ISO 8601:2004 standard notation. There are different 'standard' notations:

2009-11-01T01:59:59-07:00
20091101T015959-0700

The latter is not readable by humans (but is compact and readily read by programs). The former has the advantage that the whole time string is a 'single word', rather than 3 words in the notation I used.

Improve this answer
2

You must log in to answer this question.