Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Falsehoods Programmers believe about Time

infiniteundo.com

Post reply on HN
Print view View original

131–140 of 222 posts

Re: Falsehoods Programmers believe about Time

#131

Post by [deleted] »

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…

[deleted]

Re: Falsehoods Programmers believe about Time

#132

Post by sk5t »

frankc wrote: post #57
hcarvalhoalves wrote: post #44

35. People will just assume all APIs and standard libs that deal with dates are sane Adobe managed to build a pretty shitty Date object for ActionScript that takes days as a 1-indexed parameter, but months as 0-indexed. Hopefully ActionScript is not used in banking [1] [1] http://help.adobe.com/en_US/FlashPlatform/reference/actionsc...

This is not that insane, or at least relatively insane, because this matches the behavior of localtime(). I have heard the reason for using a 0-indexed month is for the convenience of mapping to an enum of month names.

IMHO a default month of January makes rather little sense, and would tend to facilitate subtle bugs... it seems you'd want the user to specify a month always, or maybe have a default of "indeterminate" or "Nevember"; the first position of an enum is very often the "nothing" case.

Re: Falsehoods Programmers believe about Time

#133

Post by falling »

arohner wrote: post #63

N+?? The time library in your programming language is correct. Every time library I've ever dealt with will have serious problems with at least one issue listed on the original article or in the comments here. JodaTime (on the JVM) is by far the best, but even they have problems, and are creating a new library to solve those.

> N+?? The time library in your programming language is correct.

That is almost always a better assumption than “I can write a better one”.

Re: Falsehoods Programmers believe about Time

#134

Post by gregholmberg »

einhverfr wrote: post #107
arohner wrote: post #15

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

36: Continguous timezones are no more than an hour apart. (aka we don't need to test what happens to the avionics when you fly over the International Date Line)

It's a recurring problem, too. These examples are twenty-two years apart.

"Aircraft software can be serious business" http://www.defenseindustrydaily.com/f22-squadron-shot-down-b...

"The [F22 Raptor IDL] post-incident report" http://it.slashdot.org/comments.pl?sid=224098&cid=181501...

"[undetected software bug in the] Northrop F-20 Tigershark laser inertial navigation system" http://www.f20a.com/f20ins.htm

Re: Falsehoods Programmers believe about Time

#135

Post by Osiris »

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 Time" (used by Outlook) is the same as "US/Arizona" (used by PHP among others).

Re: Falsehoods Programmers believe about Time

#136

Post by cperciva »

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 backwards. Some platforms handle setting the current time by changing the system uptime.

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.

Re: Falsehoods Programmers believe about Time

#137

Post by pestaa »

MichaelGG wrote: post #130

> 1. There are always 24 hours in a day. Can someone explain when this isn't true? Is he referring to leap seconds, or local timezone DST changes? Or something more interesting I'm failing to think of?

Every day is slightly longer than 24 hours, accumulating more than 6 extra hours every year (hence leap years.)

Other than that, I can only think of local DST changes you mentioned.

Re: Falsehoods Programmers believe about Time

#138

Post by masklinn »

brazzy wrote: post #50
JoshTriplett wrote: post #38

Earlier quoted context omitted.

From which many modern reckonings of time descend, including the one used by all modern computer systems.

Actually, almost no country outside the British Empire (and not even Scotland inside it) implemented the Gregorian reform at the same time. Britain was pretty late in doing so, too. As for "all modern computer systems", Unix time is completely ignorant about anything except seconds.

> Unix time is completely ignorant about anything except seconds

That's not correct, actually: UNIX time tracks UTC instead of TAI meaning it "corrects" for leap seconds. As a result, UNIX time is not "the number of seconds since epoch" but "86400 * (number of whole days since epoch) + (number of seconds since midnight)", and UNIX time will go forwards (never so far) and backwards on leap seconds (a second will repeat in most implementations as the day goes from 23:59:60 to 00:00:00, as they have the same timestamp).

Re: Falsehoods Programmers believe about Time

#139

Post by gregholmberg »

jcarreiro wrote: post #109
ColinWright wrote: post #51

I've been on an airplane (on the flight deck - pre 2001) watching the sun rise in the West. Sometimes local time runs backwards.

So, were you on the Concorde, or was it a Tu-144?

The terminator is only that fast near the equator. Further north, " ... it is possible to walk faster than the terminator at the poles, near to the equinoxes. The visual effect is that of seeing the Sun rise in the west."

http://en.wikipedia.org/wiki/Terminator_(solar)

Re: Falsehoods Programmers believe about Time

#140

Post by msbarnett »

MarkMc wrote: post #128
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…

Let's keep some perspective. The vast majority of software applications don't use dates from the 18th century so it's fine to for your app to assume that the Gregorian calendar always was and always will be.

...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.

Post reply on HN