Live data from Hacker News

Falsehoods Programmers believe about Time

infiniteundo.com

141–150 of 222 posts

Re: Falsehoods Programmers believe about Time

#141

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?

747-400, but a long way north.

Re: Falsehoods Programmers believe about Time

#142
post #95
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...

This was hilarious for people who had booked tickets on flights out on the 30th. Do you leave on the 29th or the 31st...? This was a real problem for the airlines and headache for a number of travellers.

Re: Falsehoods Programmers believe about Time

#146

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

DST changes are a big issue. A simple example from real life - there is a system that takes a measurement every hour, 24/7. Make a report that prints a table of the historical measurements for each day. Does your report show correctly that some days have 24 rows, some have 25 rows and some 23?

Re: Falsehoods Programmers believe about Time

#147
In Vernor Vinge's A Deepness in the Sky, the Unix epoch is still used thousands of years in the future, but "programmer archaeologists" of the time mistakenly believe that was the date when humans first landed on the moon. They also measure time in kiloseconds and megaseconds because "day" or "week" don't mean much for interstellar travelers.

https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...

Re: Falsehoods Programmers believe about Time

#148
post #128

Earlier quoted context omitted.

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.

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.

Re: Falsehoods Programmers believe about Time

#149
post #128

Earlier quoted context omitted.

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.

and KSA

Re: Falsehoods Programmers believe about Time

#150

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 use for timing quite often. I tend to do soft real time stuff and that clock seems the best suited for my tasks.

Post reply on HN