And it doesn't even mention all the bizarre things that have been done (for reasons good and bad) to time by various governments. Like adjusting from local solar time to standard GMT offset timezones (which involves skipping a given number of minutes and seconds or having them twice). Or introducing/abolishing/moving around daylight savings time. Or "super daylight savings time" with a 2 hour offset. Or moving from one side of the international date line to the other. And of course the real biggie: the Gregorian calendar reform that various countries adopted at different times between 1582 and the 1920s, skipping between 10 and 13 days depending on when they adopted it.
Falsehoods Programmers believe about Time
31–40 of 222 posts
Re: Falsehoods Programmers believe about Time
#3239. The next day after 3 Sep 1752 is 4 Sep 1752.
Re: Falsehoods Programmers believe about Time
#3335. Two timezones that differ, will differ by an integer number of hours.
Yeah, that one even made it into the EXIF standard...
Re: Falsehoods Programmers believe about Time
#3435. Two timezones that differ, will differ by an integer number of hours.
N. The offsets between two time zones will remain constant.
N+1. OK, historical oddities aside, the offsets between two time zones won't change in the future.
N+2. Changes in the offsets between time zones will occur with plenty of advance notice.
N+3. Daylight savings time happens at the same time every year.
N+4. Daylight savings time happens at the same time in every time zone.
N+5. Daylight savings time always adjusts by an hour.
N+6. Months have either 28, 29, 30, or 31 days.
N+7. The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.
Explanations:
(N)-(N+2): There exist enough jurisdictions in the world that time zone changes occur often enough to require regular updates to the time zone database, more frequently than many distribution release schedules occur.
(N+3)-(N+5): Jurisdictions change DST policies even more frequently than they change time zones.
(N+6)-(N+7): September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30.
Re: Falsehoods Programmers believe about Time
#35If you really want to stress test time handling code, try to get it to accept Feburary 29, 1900 and Feburary 29, 2000. The first doesn't exist but the second does. But really, with regards to time use whatever library came with you programming language.
That will stress it a bit, but to really torture it, see if it accepts 2012 June 30 23:59:60
Or June 1st 1905 00:02:00 in Singapore.
Re: Falsehoods Programmers believe about Time
#3635. Two timezones that differ, will differ by an integer number of hours.
N. The offsets between two time zones will remain constant. N+1. OK, historical oddities aside, the offsets between two time zones won't change in the future . N+2. Changes in the offsets between time zones will occur with plenty of advance notice. N+3. Daylight savings time happens at the same time every year. N+4. Daylight savings time happens at the same time in every time zone. N+5. Daylight savings time always a…
> September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30.
In the British Empire, anyway.
Re: Falsehoods Programmers believe about Time
#37If only someone would come up with a standard time format, surely that would solve all issues...
In all seriousness time-stamps are some of the most annoying things to compare ever.
Re: Falsehoods Programmers believe about Time
#38Earlier quoted context omitted.
N. The offsets between two time zones will remain constant. N+1. OK, historical oddities aside, the offsets between two time zones won't change in the future . N+2. Changes in the offsets between time zones will occur with plenty of advance notice. N+3. Daylight savings time happens at the same time every year. N+4. Daylight savings time happens at the same time in every time zone. N+5. Daylight savings time always a…
> September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30. In the British Empire, anyway.
From which many modern reckonings of time descend, including the one used by all modern computer systems.
Re: Falsehoods Programmers believe about Time
#3935. Two timezones that differ, will differ by an integer number of hours.
N. The offsets between two time zones will remain constant. N+1. OK, historical oddities aside, the offsets between two time zones won't change in the future . N+2. Changes in the offsets between time zones will occur with plenty of advance notice. N+3. Daylight savings time happens at the same time every year. N+4. Daylight savings time happens at the same time in every time zone. N+5. Daylight savings time always a…
My favorite eye-stabby example of this was parsing RSS feeds (with meaningless timezone abbreviations!) from sites in the southern hemisphere. Depending on the date and various last-minute laws (thank you, President Chavez), the differential would be 0, +1, +2, +2.5 or +3 hours between various points.
Re: Falsehoods Programmers believe about Time
#40The comment about KVM in CentOS is probably inaccurate--not sure what it's referring to.
In the 5.4-ish time scale, there were a lot of clock related problems. One of them had to do with frequency scaling...
PCs have many time sources. The processor has it's own internal clock that ticks at a very fast rate (nanoseconds). There's the wallclock time which ticks at a slow rate (seconds). The internal clock starts at 0 when the system boots so it can't be used for wallclock time without adjustment.
Some Operating Systems (like Linux), get the boot time from the real time clock (slow tick rate) but then compute the current time by adding the CPU internal clock to it.
The CPU internal clock (TSC) can be wildly inaccurate for various reasons. One of them is frequency scaling which actually changes the frequency of the TSC dynamically. Unfortunately, if you're changing the frequency of the TSC on the host, guests that are running and accessing the TSC directly don't realize this has happened.
So if you scale the TSC frequency by 50%, time starts moving 50% more slowly. BIOS can also scale processor speed on some servers without the OS knowing which can lead to the same problem on bare metal.
More modern processors now have fixed TSC frequencies and KVM now has a paravirtual clock source both which address this problem.
BTW, Windows does not use the TSC as a time source so Windows typically won't have this problem (although it has other problems).
Time keeping in virtualization is fun :-)