Falsehoods Programmers believe about Time • Hacker News Board

Re: Falsehoods Programmers believe about Time

#171

Post by morsch » Tue, Jun 19, 2012, 9:41 AM UTC

brk wrote: post #105

SCdF wrote: post #70

Earlier quoted context omitted.

It isn't? Can you explain that in a bit more detail?

Some examples that come to mind: 1) You're (possibly) assuming that both timestamps come from the same machine. They could be from two machines (Server timestamps a transaction start, client timestamps the end.) Clocks are not accurate, so the delta time is not correct. 2) Time A is before a DST change forward or back, Time B is after. Delta would be wrong by +/- 1 hour (assuming all other factors are tracking with a…

Timestamps are not affected by (or aware of) DST. In fact that's one reason why it's so easy to compute the time elapsed between two timestamps. From [0]:

  $ ./timetool 1130647000
    1130647000   =  Sunday  Oct 30, 2005  00:36 EDT
    1130647600   =  Sunday  Oct 30, 2005  00:46 EDT
    1130648200   =  Sunday  Oct 30, 2005  00:56 EDT
    1130648800   =  Sunday  Oct 30, 2005  01:06 EDT
    1130649400   =  Sunday  Oct 30, 2005  01:16 EDT
    1130650000   =  Sunday  Oct 30, 2005  01:26 EDT
    1130650600   =  Sunday  Oct 30, 2005  01:36 EDT
    1130651200   =  Sunday  Oct 30, 2005  01:46 EDT
    1130651800   =  Sunday  Oct 30, 2005  01:56 EDT
    1130652400   =  Sunday  Oct 30, 2005  01:06 EST
    1130653000   =  Sunday  Oct 30, 2005  01:16 EST
    1130653600   =  Sunday  Oct 30, 2005  01:26 EST
    1130654200   =  Sunday  Oct 30, 2005  01:36 EST
    1130654800   =  Sunday  Oct 30, 2005  01:46 EST
    1130655400   =  Sunday  Oct 30, 2005  01:56 EST
    1130656000   =  Sunday  Oct 30, 2005  02:06 EST
    1130656600   =  Sunday  Oct 30, 2005  02:16 EST
    1130657200   =  Sunday  Oct 30, 2005  02:26 EST
  $

So it's down to the accuracy (and synchronicity) of the clocks used to measure the timestamps: The difference between two timestamps is an accurate measure of the time elapsed (but see below), but that's probably only useful to you if the timestamps themselves are accurate.

However, leap seconds -- during which time passes, but the timestamps typically do not -- and numerical issues stemming from truncation and subtraction do have a systematic impact and reduce the accuracy of the difference. You can address the former for timestamps in the past by simply taking into account the leap seconds; you can address the latter by using higher resolution timestamps, ie. using millisecond timestamps if you need better-than-second-accuracy for the amount of time elapsed.

[0] http://www.unix.com/unix-dummies-questions-answers/18754-tim...

Re: Falsehoods Programmers believe about Time

#172

Post by halfasleep » Tue, Jun 19, 2012, 9:42 AM UTC

MarkMc wrote: post #148

msbarnett wrote: post #140

Earlier quoted context omitted.

...except that there were countries that weren't using the Gregorian calendar until well into the 20th Century , so you can't even reliably deal with dates as recent as the mid-1900s across borders under that assumption. But don't worry, they're just small countries. Like Russia. And China.

I suspect that even in China and Russia, most software will require that dates be entered as if the current Gregorian Calendar had always applied.

Software makes assumptions, though most decent time libraries will correctly combine local and date to show the skipped days. It might be a bit lazy though, running "cal sept 1752" will show the same for all locals as far as I can tell from the man page.

Re: Falsehoods Programmers believe about Time

#173

Post by prehensile » Tue, Jun 19, 2012, 9:47 AM UTC

snprbob86 wrote: post #76

brazzy wrote: post #31

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 o…

Yeah, this list is woefully incomplete. Here's another good read: http://naggum.no/lugm-time.html

Oh man, I read that article years ago, lost the link and have been unable to find it since. Thanks! Any technical document which starts with "The measurement of time has a very long history, dating back to the first records of human civilization" and has a section titled "Political Time" gets a special place in my heart.

Re: Falsehoods Programmers believe about Time

#174

Post by Muzza » Tue, Jun 19, 2012, 9:47 AM UTC

jimfl wrote: post #95

arohner wrote: post #15

35. Two timezones that differ, will differ by an integer number of hours.

The day before Saturday is always Friday. http://www.nytimes.com/2011/12/30/world/asia/samoa-to-skip-f...

Hmm. I've written code which assumes that Monday is two days after Saturday and one day after Sunday.

Re: Falsehoods Programmers believe about Time

#175

Post by obtu » Tue, Jun 19, 2012, 9:49 AM UTC

rplnt wrote: post #55

grimlck wrote: post #30

Earlier quoted context omitted.

That will stress it a bit, but to really torture it, see if it accepts 2012 June 30 23:59:60

Well, you don't know if 31.12.2015 will have a 23:59:60 or no. These seconds are announced just prior to being added, the system couln't possibly know it.

June is already decided. We'll know either way about the December second when the next bulletin C is published, sometime next July: http://hpiers.obspm.fr/iers/bul/bulc/

Re: Falsehoods Programmers believe about Time

#176

Post by cperciva » Tue, Jun 19, 2012, 9:50 AM UTC

jvdh wrote: post #153

cperciva wrote: post #136

Some more falsehoods: 1. Time never goes backwards (as other people have pointed out, time zones break this). 2. UTC time never goes backwards (as other people have pointed out, leap seconds break this). 3. The system boot time never changes. On most platforms, the current time is defined as "boot time plus uptime", and setting the current time is performed by changing the boot time. 4. System uptime never goes backw…

UTC time does not go backwards. Leap seconds are implemented as a minute with 61 seconds.

Ok, I oversimplified. UTC time does not go backwards, but the value returned by POSIX time(3) -- which is supposed to be the number of seconds since 1970-01-01 00:00:00 UTC -- does. (Assuming you have sub-second precision, of course; time_t isn't required to be an integer type, and there's other APIs which access the same UTC-seconds clock and provide microsecond or nanosecond precision.)

Re: Falsehoods Programmers believe about Time

#177

Post by brk » Tue, Jun 19, 2012, 9:56 AM UTC

morsch wrote: post #171

brk wrote: post #105

Earlier quoted context omitted.

Some examples that come to mind: 1) You're (possibly) assuming that both timestamps come from the same machine. They could be from two machines (Server timestamps a transaction start, client timestamps the end.) Clocks are not accurate, so the delta time is not correct. 2) Time A is before a DST change forward or back, Time B is after. Delta would be wrong by +/- 1 hour (assuming all other factors are tracking with a…

Timestamps are not affected by (or aware of) DST. In fact that's one reason why it's so easy to compute the time elapsed between two timestamps. From [0]: $ ./timetool 1130647000 1130647000 = Sunday Oct 30, 2005 00:36 EDT 1130647600 = Sunday Oct 30, 2005 00:46 EDT 1130648200 = Sunday Oct 30, 2005 00:56 EDT 1130648800 = Sunday Oct 30, 2005 01:06 EDT 1130649400 = Sunday Oct 30, 2005 01:16 EDT 1130650000 = Sunday Oct 30…

True, but that depends on what exactly you're reading as a timestamp.

Using localtime in perl for example (a very common method to read the system time) does not return a timestamp, but returns a formatted string (see: http://perldoc.perl.org/functions/localtime.html) that could easily be thrown off by a DST changeover.

Re: Falsehoods Programmers believe about Time

#178

Post by cperciva » Tue, Jun 19, 2012, 10:09 AM UTC

exDM69 wrote: post #150

cperciva wrote: post #136

Some more falsehoods: 1. Time never goes backwards (as other people have pointed out, time zones break this). 2. UTC time never goes backwards (as other people have pointed out, leap seconds break this). 3. The system boot time never changes. On most platforms, the current time is defined as "boot time plus uptime", and setting the current time is performed by changing the boot time. 4. System uptime never goes backw…

> 5. POSIX's CLOCK_MONOTONIC never goes backwards. On some platforms and virtualization environments this can break with CPUs shared between virtual machines. > 6. On systems without virtualization, CLOCK_MONOTONIC never goes backwards. On some platforms this can occur due to clock skew between CPUs. Could you explain these situations in more detail? Or cite a source I can take a look at? CLOCK_MONOTONIC is what I us…

(5) is just a specific instance of the general principle "virtualization screws everything up". The most common issue is with virtualization systems trying to hide the fact that time is being "stolen" by the hypervisor and/or other domains.

(6) is a case of "synchronization is really hard" combined with "benchmarks measure system performance, not system correctness". Most high-performance timing these days involves reading an on-die clock counter, scaling, and adding a base (boot time) value. For that to work on SMP, the clocks need to be synchronized -- and they don't start that way, since CPU #0 is enabled first and does some hardware probing before it turns the other CPUs on. Even worse, on many platforms, power-saving features will slow down the clock, resulting in the counters getting out of sync.

As alexs says, CLOCK_MONOTONIC should be monotonic... but in reality, it's much faster to return a mostly-good-enough value. In FreeBSD, in addition to CLOCK_{UPTIME, REALTIME, MONOTONIC}, we have CLOCK__{FAST, PRECISE} so that applications can choose between accuracy and performance.

CLOCK_MONOTONIC is what I use for timing quite often. I tend to do soft real time stuff and that clock seems the best suited for my tasks.*

As long as you avoid virtualization, turn off all power-saving features, and your "soft real time" can tolerate non-monotonicity on the sub-microsecond scale, you should be safe.

Re: Falsehoods Programmers believe about Time

#179

Post by BrandonM » Tue, Jun 19, 2012, 10:11 AM UTC

Osiris wrote: post #135

I work on a calendar application and I can attest to all kinds of issues dealing with time, dates, and time zones. It's very difficult to get right and most of the time we just hope that for our purposes it's close enough. A big issue is dealing with timezone conversions especially because different applications represent time zones with different english language versions of the names, like "US Mountain Standard Tim…

> "US Mountain Standard Time" (used by Outlook) is the same as "US/Arizona" (used by PHP among others).

It's not quite that simple. During Daylight Saving Time, Arizona stays on US Mountain Standard Time; i.e., it's the same as Pacific Daylight Time and one hour behind Mountain Daylight Time. During the rest of the year, Arizona is on the same time as the rest of Mountain Standard Time, or one hour ahead of Pacific Time.

Re: Falsehoods Programmers believe about Time

#180

Post by [deleted] » Tue, Jun 19, 2012, 10:16 AM UTC

cperciva wrote: post #176

jvdh wrote: post #153

Earlier quoted context omitted.

UTC time does not go backwards. Leap seconds are implemented as a minute with 61 seconds.

Ok, I oversimplified. UTC time does not go backwards, but the value returned by POSIX time(3) -- which is supposed to be the number of seconds since 1970-01-01 00:00:00 UTC -- does. (Assuming you have sub-second precision, of course; time_t isn't required to be an integer type, and there's other APIs which access the same UTC-seconds clock and provide microsecond or nanosecond precision.)

[deleted]