Falsehoods Programmers believe about Time

http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

by mcfunley • 14 years ago

364 213 14 years ago

infiniteundo.com

cpeterso3• 14 years ago

Also, time is unidirectional.

tomjen33• 14 years ago

Well time would be unidirectional, right?

The computer clock might not be.

zanny• 14 years ago

Ooooh, nerd time!

If you are moving faster than the speed of light, you are perceiving whatever you are moving away from in reverse, because the light you are seeing was generated before when you left. (you are passing into light that is older than the light you started with). In terms of space-time, you would then be going backwards in time, if your point of reference for time was the Earth (and hint, given that we have all these nuanced time thingamajigs, it is)

DanWaterworth2• 14 years ago

I think this would be better stated as, "the system clock increases monotonically".

saraid216• 14 years ago

Can someone explain #1? I suspect it has to do with crossing time zones?

moskie• 14 years ago

Day light savings transition days. When you skip ahead, that day has 23 hours in it. When you fall back, it has 25.

mbrubeck• 14 years ago

Also leap seconds: https://en.wikipedia.org/wiki/Leap_second

JoshTriplett4• 14 years ago

Also, any other change to the system clock. NTP will either slew or step the system clock to keep it synchronized with the upstream time source. And the user can explicitly set the clock, as well. See also assumptions 9 and 10.

malkia• 14 years ago

What moskie explained, but got me thinking - if somehow your laptop always synchronizes with the current zone, and you are in a airplane flying east->west, or west->east?

baddox• 14 years ago

Who believes these things? February is always 28 days long? Any 24-hour period will always begin and end in the same day (or week, or month)? A week always begins and ends in the same month?

sp3322• 14 years ago

He's talking about test code. So if those test cases are missing, but the programmer thinks the tests are thorough, then it looks like the programmer believes those things (or forgot that they weren't true).

DougBTX• 14 years ago

A bad test might boil down to,

    assert(month(now()) == month(now() + 24.hours))

then fail from time to time.

maggit2• 14 years ago

I thought about the same thing. I choose to read the title as "Falsehoods programmers seem to believe about time". Or "act as if they believe" in place of "seem to believe".

I can easily imagine somebody introducing a bug that relies on a 24 hour period ending in the same month as it began.

gms7777• 14 years ago

Perhaps the accurate title is "Assumptions programmers make about time"

antidoh2• 14 years ago

Bugs happen. Especially thoughtless ones.

The title might better have been "Things programmers have tried to do with time."

sp3322• 14 years ago

About #7: doesn't a month always end in the same year it started?

tomjen33• 14 years ago

Well I guess it is possible if you used some Chinese or Jewish calendar or something like that.

But at least in the western system it shouldn't be possible to it to span years.

stan_rogers• 14 years ago

The way you're thinking about it, yes -- but the passage of a month may take you from December the [mumbleth] to January the [mumbleth], which are in different years. For some strange reason, code in the wild doesn't always account for that, so the due date for an item may well be eleven months before the request was entered.

hcarvalhoalves3• 14 years ago

I like to call this kind of bug "New Year's Wake-up Call from Hell".

sses• 14 years ago

One I caught recently: The difference between the current time and one week from the current time is not always 7 * 86400 seconds.

By noticing an automated test that failed 2 weeks out of the year.

Corvus• 14 years ago

Between 1582 and 1752 England had two different New Year's Days, January 1 and March 25, used for different purposes. The same day had different years depending on who you were talking to. See http://en.wikipedia.org/wiki/Dual_dating.

rmc10• 14 years ago

The tax year in UK still start/end on March 25th IIRC

Ralith• 14 years ago

One of my favorites, encountered in the wild: Your system will never need to handle a time before 1970.

hartez• 14 years ago

Ran into a similar one about ten years ago; a medical records system with the assumption that you wouldn't need dates before 1/1/1900.

You know who goes to the doctor a lot? Centegenarians.

arohner3• 14 years ago

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

aardvark1792• 14 years ago

36. Two timezones that differ will differ by an integer number of half hours.

37. Okay, quarter hours.

38. Okay, seconds, but it will be a consistent difference if we ignore DST.

bazzargh• 14 years ago

39. If you create two date objects right beside each other, they'll represent the same time. (a fantastic Heisenbug generator)

40. You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.

sethg2• 14 years ago

What has a non-integral number of seconds?

I just found out today about Calcutta time, which until 1948 was GMT+05:30:21, but I didn’t realize it could be even worse than that.

brazzy5• 14 years ago

Yeah, that one even made it into the EXIF standard...

JoshTriplett4• 14 years ago

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.

brazzy5• 14 years ago

> September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30.

In the British Empire, anyway.

aristus• 14 years ago

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.

lambda• 14 years ago

> September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30.

That's only in the British Empire. Other countries moved to the Gregorian Calendar at different times. It began being adopted on 15 October 1582 (the day after 4 October 1582) in some Roman Catholic countries (Spain, Portugal, Italy, Poland). Russia didn't switch until 1918.

So, you could also have:

N+8. There is only one calendar system in use at one time.

And the list hasn't actually covered the Gregorian calendar at all, since many people may not know the actual leap year rule.

N+9. There is a leap year every year divisible by 4.

The actual rule is that there is a leap year every year divisible by 4, except those divisible by 100, with a further exception to that exception for years divisible by 400, (so there is a leap year on such years). The year 2000 is one such year divisible by 400, so we have not yet passed a year divisible by 4 which is not a leap year since the invention of computers.

chris_wot• 14 years ago

N+8. It will be easy to calculate the duration of x number of hours and minutes from a particular point in time.

The reason this is impossible on Windows and downright awkward on Unix is because DST changes from time to time. Unless you have something like tzinfo, you cannot work out a particular date and time by merely adding a duration to another date and time in the past.

Instead, you must work out the timezone you are doing the calculation in, then work out whether the duration needs to incorporate a DST change, which involves working out what that DST changeover date and time was...

Of course, it's impossible on Windows because Microsoft only give the start and end datetime offsets for the current year. Amazingly, after all the patches they've had to issue to fix DST changes over the years, they still haven't implemented a Windows equivalent of tzinfo yet. And may never do so, even though they really aught to, given they are one of the leaders in calendaring software.

jimfl• 14 years ago

The day before Saturday is always Friday.

http://www.nytimes.com/2011/12/30/world/asia/samoa-to-skip-f...

benjaminRRR• 14 years ago

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.

Muzza• 14 years ago

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

einhverfr3• 14 years ago

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)

gregholmberg2• 14 years ago

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

adavies427• 14 years ago

17% of the world's population lives in a single .5 timezone (https://en.wikipedia.org/wiki/Indian_Standard_Time), so i'd hope that one's not too widespread....

apaprocki5• 14 years ago

Sometimes time is simplified on purpose:

  15.9.1.2 Day Number and Time within Day # Ⓣ
  
  A given time value t belongs to day number
    Day(t) = floor(t / msPerDay)
  where the number of milliseconds per day is
    msPerDay = 86400000

http://es5.github.com/#x15.9.1.2

arohner3• 14 years ago

36. GMT and UTC are the same timezone.

TazeTSchnitzel5• 14 years ago

36b. Britain uses GMT. Not true, we use BST (British Summer Time) during the summer.

tomjen33• 14 years ago

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

grimlck• 14 years ago

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

brazzy5• 14 years ago

Or June 1st 1905 00:02:00 in Singapore.

hcarvalhoalves3• 14 years ago

Now that's just mean! ;)

rplnt• 14 years ago

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.

yxhuvud3• 14 years ago

Or 30th February 1712.

keltex• 14 years ago

35. There are years past 2079. SQL Server smalldatetime only goes up to June 6, 2079

apaprocki5• 14 years ago

Checking the terminal, I don't see any corporate bonds maturing in 2079 yet. But I do see a handful in every year >= 2070 and <= 2077. So maybe a few more years and some people / firms will start hitting bugs...

brazzy5• 14 years ago

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.

crazygringo• 14 years ago

My favorite is when Daylight Savings Time started after an election in Brazil, but before the date for the election runoffs. Turned out the voting machines couldn't be changed to handle the time change. Solution? They just pushed back the date when DST started until after the runoffs.

http://statoids.com/tbr.html -- "Note that the government frequently changes its mind [about DST] at the last minute."

yxhuvud3• 14 years ago

https://en.wikipedia.org/wiki/Swedish_calendar is my personal favorite when it comes to the transition to gregorian.

snprbob86• 14 years ago

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

prehensile• 14 years ago

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.

apaprocki5• 14 years ago

Also, computer systems have different Gregorian calendars. Your system could use the proper Gregorian calendar and a system you're communicating with could be using the proleptic Gregorian calendar. Most people don't notice the difference because dates aren't frequently slung around < 1582 in the modern world, but if a system has an idea of an "unset" date being equal to 1/1/1 it could lead to an error if transmitted to the other, resulting in an invalid date 12/30/0.

vidarh• 14 years ago

Not to mention dealing with the numerous differences in when the Gregorian calendar was adopted, which is great fun if you need to deal with dates even back to the early 1900's across borders.

E.g. the "October revolution" falls in November - Russia didn't change until the Bolcheviks took power in 1917. And Greece didn't switch until 1923... China switched in 1912, but different factions in the civil war used different systems and it wasn't until 1929 they got a single (Gregorian) calendar again.. And there are many other countries that switched "recently".

MarkMc4• 14 years ago

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.

msbarnett• 14 years ago

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

apaprocki5• 14 years ago

39. The next day after 3 Sep 1752 is 4 Sep 1752.

jamesgeck0• 14 years ago

40. There was a 3 Sept 1752.

aardvark1792• 14 years ago

I love that people in this thread think the adoption of the Gregorian calendar happened on a single date, it's way more complex than that.

zipdog• 14 years ago

In Sweden there was a 30th February 1712

rmc10• 14 years ago

In the British Empire/UK.

crisnoble• 14 years ago

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

kstenerud• 14 years ago

http://xkcd.com/927/

aliguori• 14 years ago

The 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 :-)

hcarvalhoalves3• 14 years ago

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

frankc• 14 years ago

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.

sk5t3• 14 years ago

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.

DanWaterworth2• 14 years ago

How about, "the difference between two timestamps is an accurate measure of the time that elapsed between them".

morsch2• 14 years ago

What's wrong about that? Numerical issues due to the truncation (ie 2500ms → 2s) and subsequent subtraction? Leap seconds? Anything else?

yxhuvud3• 14 years ago

Measurement error, and the fact that the timestamps may not be taken on the same machine.

SCdF• 14 years ago

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

brk2• 14 years ago

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

3) Both times are taken on the same machine, but far enough apart that clock drift plays a factor.

4) Both times are taken on the same machine, but an ntptimesync cron job kicked off in between them and adjusted the system clock.

efnx2• 14 years ago

What about time can you depend on?

jhawk283• 14 years ago

You can't. Time is a completely relative concept. If you expect order, use a sequence.

efnx2• 14 years ago

Exactly.

psykotic• 14 years ago

ObLink: Erik Naggum's The Long, Painful History of Time (http://naggum.no/lugm-time.html)

ColinWright2• 14 years ago

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

jcarreiro• 14 years ago

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

gregholmberg2• 14 years ago

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)

ColinWright2• 14 years ago

747-400, but a long way north.

dfranke• 14 years ago

You didn't mention any assumptions that get screwed up by the presence of leap seconds.

N. There are 60 seconds in every minute. N+1. UNIX timestamps always advance monotonically.

arohner3• 14 years ago

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.

henrikschroder• 14 years ago

> and are creating a new library to solve those.

Now they have N+1 problems.

MarkMc4• 14 years ago

I think that for the vast majority of real-world software applications JodaTime is bloated and unnecessary.

Most applications need only three 'classes' to represent time:

1. A timestamp (ie. number of milliseconds since midnight on 1 January 1970 GMT)

2. A Gregorian Date (ie. three numbers representing day, month, year)

3. A TimeZone (to convert between 1 and 2)

In Java the first and third types are perfectly represented by java.util.Date and java.util.TimeZone. The second class can be represented by something like this: http://calendardate.sourceforge.net/

(Disclaimer: I wrote CalendarDate)

rmc10• 14 years ago

1. A timestamp (ie. number of milliseconds since midnight on 1 January 1970 GMT)

You know that's not unix time, right? Unix time doesn't include leap seconds.

falling• 14 years ago

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

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

endlessvoid94• 14 years ago

If you haven't read "Great unsolved problems in computer science", I'd highly recommend it: http://algeri-wong.com/yishan/great-unsolved-problems-in-com...

TL;DR: calendaring is hard. really hard.

Florin_Andrei• 14 years ago

> 32. A time stamp of sufficient precision can safely be considered unique.

I'm so guilty of that one.

ams6110• 14 years ago

This sort of stuff is why I scream "NNNNOOOOOOOOOOOOOO!!!!!!" when people store date/time as integers (i.e. "unix timestamps") when almost every database and programming language has a proper date or datetime data type, and a boatload of library functions that correctly compute differences between dates, handle leap years and time zones, etc. Well maybe not always correctly, but it's more likely that YOU will screw up your date math than it is that the well-tested date library will.

rdwallis2• 14 years ago

At least in Java, storing a date/time as a primitive improves immutability and is a good pattern.

You don't expose the underlying long value publicly so you end up with something like the following:

private long primitiveDate;

public Date getDate() { return new Date(primitiveDate); }

-----

This prevents calling methods from doing something stupid like:

o.getDate().setTime(123455L)

to modify a date that shouldn't be editable.

taftster• 14 years ago

Or possibly better:

private Date date;

public Date getDate() { return new Date(date.getTime()); }

rlpb• 14 years ago

> when almost every database and programming language has a proper date or datetime data type, and a boatload of library functions that correctly compute differences between dates, handle leap years and time zones, etc.

In Unix-land, this data type and boatload of library functions is the operating system. The system provides and deals with local time conversion when necessary. If your application isn't very involved with time (eg. it's not a calendar or scheduling application) then it is sensible to use Unix timestamps.

This ties you to a Unix OS, which isn't usually too bad a decision since other more important things do as well. On the other hand, using your programming language or database ties you to that database or language, which is arguably worse.

apaprocki5• 14 years ago

> In Unix-land, this data type and boatload of library functions is the operating system.

Which can lead to problems as well. Basically when dealing with "local" time (DST), you need a reliable source of data and the question boils down to whether you want system administrators to keep OSes patched and up-to-date every time tzdata is updated, or whether that should be handled at the application layer.

Java chooses to bake in tzdata, and so do a number of other app-layer platforms. JS in the browser relies on the OS instead of bundling binary tzdata. Windows and a few commercial *nix platforms do not bundle tzdata either and maintain their own definitions. The crowd-sourced tzdata has demonstrated itself better than even what Microsoft ships in Windows. I don't know anyone who would claim a dataset other than tzdata is "better".

There might come a point in time where browsers have sufficiently advanced automatic patching invisible to the end user that they would be better off bundling tzdata internally rather than relying on the OS because they can guarantee their data is better in a higher percentage of cases. It all comes down to whose update system is more seamless and more likely to occur given all the external factors that come into play. (e.g., a user might have local machine privileges to apply browser updates, but not OS updates)

sk5t3• 14 years ago

IMHO you will change your tune with more time and experience; numerics are often more portable and unambiguous than string or serialized-object alternatives... e.g., if you pass around datetimes as "int64 count of 100-ns intervals since 1-1-1601 UTC" there is little opportunity for someone who doesn't know how to use it to get a quasi-usable yet incorrect datetime out of it.

Also note, there are plenty of database systems that either have no proper datetime datatype, or have primarily datetimes that include no TZ info.

rmc10• 14 years ago

There's a standard for that. ISO 8601. Use that. Don't make up your own.

jhawk283• 14 years ago

He missed the myth that "Time always moves forward"

adobriyan• 14 years ago

The myth is "Time always moves equally forward everywhere".

mck-• 14 years ago

There needs to be an Internet Standard Time/Date -- at least in terms of formatting.

estel• 14 years ago

What about ISO 8601? http://en.wikipedia.org/wiki/ISO_8601

jhawk283• 14 years ago

Another way to look at time is this: The only correct clock is a broken one which is right twice a day.

user49598• 14 years ago

You forgot about daylight savings.

If the day is one on which we either spring forward or fall back and the time the clock reads somewhere in the shift hour, then the clock will be right either 1 or 3 times that day. And it's different in different countries.

https://en.wikipedia.org/wiki/Daylight_saving_time#Procedure

jmpeax• 14 years ago

"The smallest unit of time is a milli/second" seems a bit silly, as it really depends on your application. Is he expecting programmers to implement time in Planck units?

srparish• 14 years ago

It's not uncommon for languages and libraries to assume that millis are the smallest resolution. Java is getting better, but is still pretty hit or miss. But if you're writing performance sensitive code you're definitely in micros and maybe in high nanos. There's a lot of those in a millisecond.

NoahSussman8• 14 years ago

The specific issue that bit me wrt units of time was seconds vs. milliseconds. This came up the first time I needed to mix PHP time stamps with Jenkins build log time stamps. One is in seconds, the other in milliseconds. Unfortunately the PHP date() function exhibits odd behavior when a time stamp contains two extra digits. I could have saved myself the debugging time had I not been so attached to the assumption that time stamps are always in seconds rather than sometimes in milliseconds.

pjscott• 14 years ago

This is why I really like logical clocks: by abandoning the primitive and outdated concept of "time" altogether, they allow you to deal reliably with causality, which is often all you're really interested in.

http://en.wikipedia.org/wiki/Lamport_timestamps

http://en.wikipedia.org/wiki/Vector_clocks

That said, UTC timestamps since the epoch are one of the more straightforward ways of dealing with time, if you must sully your hands with the foul concept of time at all.

maw• 14 years ago

> That said, UTC timestamps since the epoch are one of the more straightforward ways of dealing with time, if you must sully your hands with the foul concept of time at all.

Definitely. Leave their rendering to the experts, but to store times and dates in any other way is indefensible.

rmc10• 14 years ago

UTC timestamps since the epoch

Since we add leapseconds, and UTC includes those leap seconds, it's hard to know "time since the epoch". For example, unix/posix time is not the number of seconds since the epoch.

bluesmoon• 14 years ago

Speaking of timestamps being in recognizable formats, here's a list of interesting timestamps I've seen on (mostly) iOS devices: http://stackoverflow.com/questions/11023086/how-do-i-interpr...

If anyone has any idea about what they could possibly mean, I'd much appreciate it.

stox• 14 years ago

Missed the most important one for this month, minutes always have 60 seconds. Except for the end of this month, when one minute will have 61 seconds, ie, Leap Second.

Shenglong• 14 years ago

Also don't forget that different time zones convert to DST at different offsets, and some places don't observe DST altogether. Oh, and some places go backwards.

lacker• 14 years ago

Not just "some places" go backwards. UTC itself can jump backwards during a leap second.

http://en.wikipedia.org/wiki/Leap_second

uvTwitch• 14 years ago

"This will only take a few minutes."

NoahSussman8• 14 years ago

Heh for this I like Cheops' Maxim: "nothing is ever built on time or within budget." There's also Hofstadter's Law: "it always takes longer than you expect, even when you take into account Hofstadter's law."

technomancy• 14 years ago

I can't believe this omits my personal favourite misconception: "Time always goes forwards."

finnw• 14 years ago

N. The local time offset (from UTC) will not change during office hours.

I got bitten by this once when developing a scheduling tool for project management. Since daylight-saving offset changes were always close to midnight, I assumed they would not occur while anyone was using my program (and there was no point in using it outside "office hours.")

Then a technician on a night shift used my program on the night DST kicked in, it went into an infinite loop and took down the CRM database server, disabling automatic software updates and an (unrelated) DRM system.

michaelochurch• 14 years ago

Thread.sleep(1000) sleeps for 1000 milliseconds.

cpeterso3• 14 years ago

Or that Thread.sleep(1000) sleeps for >= 1000 milliseconds.

TazeTSchnitzel5• 14 years ago

Or that Thread.sleep(x) is anywhere near x.

derleth2• 14 years ago

A meta-misconception: It's possible to establish a total ordering on timestamps that is useful outside your system.

Virtual machines can be screwed with comprehensively. So can non-virtual ones, come to that, and your software likely isn't in a position to tell that it's already seen 02:34:17 GMT 2013-05-25 five times already.

So what can you do about that? Bloody nothing. Absolutely nothing whatsoever. You're screwed. Everything you could do can be screwed with in ways your program can't defend against.

The lesson: Don't worry about bugs you can't fix. Refusing to play games you can't win will keep your hair in your head a lot better than knowing the intricacies of human timekeeping systems past and present.

einhverfr3• 14 years ago

I was reading this and realizing that he was mixing two very different things: design considerations and design errors. Treating every year as 365 days is a design error. Leap years will break it. "Timezones next to eachother don't require changes of more than 1 hr" might also doom that F22 flying across the international date line (ok, I am assuming that was more of a test assumption than a code assumption).

On the other hand, requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration. This is why Kerberos is usually used with something like NTP.

But beyond this there are a lot of things you can't do (like expire cookies) if you don't assume that client and server have similar times on their clocks. Sometimes it makes sense to require things you can't assume to always be true.

derleth2• 14 years ago

> requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration.

Right. I love this. You can't assume it unless you document it as a requirement and make someone else make it true for all the systems your software runs on.

Never forget that specifications are a contract, an agreement entered into between the implementer and the user. If either side lets down their end, the agreement is void and the software can only fail. Either. Side.

Even if you have a mathematical proof that your software is correct, it's still only correct given certain assumptions taken as axioms in the proof. Violate those axioms and your software can't be held responsible.

adavies427• 14 years ago

> Even if you have a mathematical proof that your software is correct, it's still only correct given certain assumptions taken as axioms in the proof. Violate those axioms and your software can't be held responsible.

"Beware of bugs in the above code; I have only proved it correct, not tried it." - knuth

NoahSussman8• 14 years ago

I could tell you some stories about not being able to expire cookies.

darylteo• 14 years ago

Wasn't there a post about how 1 day this year will be 1 second longer? Can't remember it... leap second?

acoster• 14 years ago

Yes - June the 30th has a leap second ( http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat ).

rickdangerous1• 14 years ago

"7. 7.A week (or a month) always begins and ends in the same year." Not sure what the (or a month) is doing there. I'm pretty sure the end of december is the end of the year and the beginning of January is the beginning of the year. A month can't span multiple years...can it?

NoahSussman8• 14 years ago

You are right. I said "a month" but I meant something more like "a period of 28 days" or "a month-long period." I'll think about how to word this more clearly.

rmc10• 14 years ago

Years start on Sept. 11th in Ethiopia http://en.wikipedia.org/wiki/Ethiopian_calendar

damian2000• 14 years ago

DST is an evil perpetrated by curtain and blind manufacturers so that their products need replacing more often due to UV damage. Oh yeah, its the cause of global warming as well.

MichaelGG• 14 years ago

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

pestaa• 14 years ago

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.

PeterisP• 14 years ago

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?

Osiris• 14 years ago

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

BrandonM• 14 years ago

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

adavies427• 14 years ago

the "country/(city/region)" notation is from zoneinfo, the standard unix timezone system. "X standard time" (and "X daylight time") are the common names most people in america use when referring to timezones.

zoneinfo's form has the benefit of having a nice, unambiguous way to refer to the various daylight-saving time exceptions (arizona, indiana, hawaii, etc.).

recently i've seen huge timezone lists that basically throw in the kitchen sink--they'll have the entire zoneinfo set, the common american names, miscellaneous other common regional names (euro, australia, etc.) and raw whole-hour offsets as well. makes for a long drop-down to navigate....

cperciva4• 14 years ago

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.

exDM69• 14 years ago

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

__alexs• 14 years ago

If CLOCK_MONOTONIC goes backwards your platform's implementation is broken. As defined in POSIX it does not ever go backwards. It counts the time since an unspecified point in the past that never varies after system start-up.

If your process is rescheduled to a different CPU, it must still go forwards regardless of TSC variance between the CPUs.

Of course if your uptime hits 68 years or so, the clock will wrap. If your app can't have any downtime in 68 years though I hope you've got the budget to think about this sort of thing :)

cperciva4• 14 years ago

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

jvdh2• 14 years ago

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

emmapersky• 14 years ago

It can also, theoretically be a minute with 59 seconds, though I don't believe this has ever happened.

cperciva4• 14 years ago

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

nsns• 14 years ago

You can sum most of it up with: the belief that calendrical (human-conventional) time is identical to, or acts the same as, or is inherently related to, physical time.

JoshTriplett4• 14 years ago

I'd question #34 on this list somewhat: while formats like mm/dd/yyyy and dd/mm/yyyy definitely allow ambiguous interpretations, the ISO format yyyy-mm-dd seems fairly unambiguous; I've never seen any instance of yyyy-dd-mm floating around to confuse it with.

mooism22• 14 years ago

It's ambiguous for human users who are not familiar with the format. Some people may not even recognise it as a date, in some contexts. (2012-06-19, that's 1,987 right?)

TazeTSchnitzel5• 14 years ago

Make it clear, then. Put "Date:" next to it, and y m d above it in small type.

cpeterso3• 14 years ago

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

pm24601• 14 years ago

My recent favorites wrong assumptions:

1. The year is 2012. In Thailand, the year is 2555. In Malaysia, the year is 1433.

2. But surely that is not used on computers and the web? http://www.railway.co.th/home/Default.asp?lenguage=Eng (look on the right side: "booking can be until : 18/8/2555"

rmc10• 14 years ago

In Ethiopia it's about 2004 http://en.wikipedia.org/wiki/Ethiopian_calendar

TazeTSchnitzel5• 14 years ago

In North Korea it's 100 IIRC

jasey• 14 years ago

I took over from Snr dev who made 2 simple and bad time mistakes.

1) implementing their own DateAdd functionality in c# and forgetting about leap years.

2) thinking the app server and db server's time would never get out of sync.

Fml he was so bad I wanted to kill him almost every day and got paid quite a bit more than me

edanm2• 14 years ago

How about some calendaring issues I'm sure any Israeli is familiar with:

1. Weeks start on Monday.

2. Days begin in the morning.

3. Re: 2, holidays span an integer number of whole days.

Explanations:

1: In Israel, the week starts on Sunday. Most programs have support for changing the "start of week day". Most programs.

2-3: In the Jewish calendar, the day starts when the moon comes out. This means that holidays that most calendars write as "Wednesday" will actually start on Tuesday night, and last until Wednesday night.

Mvandenbergh• 14 years ago

Or anyone living in the Arab Middle East where: 1. Weeks start on a Sunday 2. Friday and Saturday are the weekend, except where it's Thursday and Friday 3. Some countries have changed their weekends in the last 10 years to Fri/Sat to make doing business internationally easier 4. Not everyone has a two-day weekend 5. Religious holidays depend on moon sightings and cannot be precisely predicted ahead of time

adavies427• 14 years ago

> In the Jewish calendar, the day starts when the moon comes out.

say what? afaik (speaking as a jew here), it's when the sun goes down. (moonrise, averaged over all time, happens at any point in the 24-hour cycle.)

possibly you're thinking of when (jewish calendar) months start?

edanm2• 14 years ago

Well technically it's when 3 stars come out.

Actually I just checked to make sure, it turns out the 3 stars thing is based on a definition by Maimonides: http://en.wikipedia.org/wiki/Jewish_calendar#Measurement_of_....

georgew3• 14 years ago

Actually, in Jewish tradition, children are taught that the day begins at sunset. The justification comes from Genesis... "And God called the light Day, and the darkness he called Night. And the evening and the morning were the first day."

The Moon is not mentioned.

jheriko• 14 years ago

Yes, it always strikes me as newbie amateur code when software uses timestamps to check for file modifications.

I'm looking at you Xcode...

I hit this problem once 10 years ago and learned the lesson ffs.

TazeTSchnitzel5• 14 years ago

So what does make use then?

gwalker• 14 years ago

I've always thought that the GNU date command captured this confusion well.

On Linux, if you run `info date` and go to "input date formats":

     Our units of temporal measurement, from seconds on up to months,
     are so complicated, asymmetrical and disjunctive so as to make
     coherent mental reckoning in time all but impossible.  Indeed, had
     some tyrannical god contrived to enslave our minds to time, to
     make it all but impossible for us to escape subjection to sodden
     routines and unpleasant surprises, he could hardly have done
     better than handing down our present system.  It is like a set of
     trapezoidal building blocks, with no vertical or horizontal
     surfaces, like a language in which the simplest thought demands
     ornate constructions, useless particles and lengthy
     circumlocutions.  Unlike the more successful patterns of language
     and science, which enable us to face experience boldly or at least
     level-headedly, our system of temporal calculation silently and
     persistently encourages our terror of time.

     ...  It is as though architects had to measure length in feet,
     width in meters and height in ells; as though basic instruction
     manuals demanded a knowledge of five different languages.  It is
     no wonder then that we often look into our own immediate past or
     future, last Tuesday or a week from Sunday, with feelings of
     helpless confusion.  ...

     -- Robert Grudin, `Time and the Art of Living'.

MicahWedemeyer• 14 years ago

While these are all valid issues, and good to be aware of, don't rush out and fix all your "broken" code. Plus, don't climb up on a pedestal and lecture your fellow developers on their "falsehoods" about time. Use your experience to know when exactness is important and when it's not.

kvz• 14 years ago

I assumed a year had 52 weeks. 2009 had 53.

adavies427• 14 years ago

* highly-precise (nano-second or better) time has any intrinsic meaning at all (relativity)

adavies427• 14 years ago

* floats are ever a good idea for storing time. a system i use (no, not excel) has one of its time types defined as a double of days since their epoch. the problem is that it's universally represented in the interface as a timestamp to millisecond precision, and many different values may have the same string representation.

i just ran a quick test, and for a specific millisecond around now, about 13,000 distinct timestamps have the same string representation. if you use that string representation as a serialization of any one of those timestamps, it will always map back to a single float value, which will be only one of those 13,000, meaning the others aren't round-trippable.

the system implements a comparison tolerance for floating point numbers, but this helps only slightly, as only about 1100 of those 13,000 test as equal to the one you get if you enter it as a string.

the end result is that you can have data printing to the screen that you can't actually find in the system because its string representation doesn't match its internal one due to precision issues.

(the solution is not to use the type--they deprecated it in favor of one based on longs of nanos several years ago.)

charlieok• 14 years ago

From the headline, my first thought was that this was going to be about estimating development time/effort on a project.

NoahSussman8• 14 years ago

Falsehoods we believe about estimating development time/effort:

1. For any non-trivial project, it is possible to estimate development time and/or effort with a reasonable degree of accuracy.

adavies427• 14 years ago

* durations and points are commensurate

points in time are relative to some fixed point, and are (more or less) dimensionless. durations are not, and are (more or less) vectors. this has a couple consequences: durations are independent of epoch, while points aren't, and only certain types of math make sense with each.

basically, the only thing you can do with two points is subtract them (yielding a duration)--the rest of arithmetic (including addition) is meaningless. the only things you can do with a point and a duration is add or subtract them (yielding a point). you can't do anything at all with a point and a dimensionless scalar. the only things you can do with two durations is add or subtract them (yielding a duration) or divide them (yielding a scalar). the only things you can do with a duration and a scalar is multiply or divide them.

(personally i'd say that even the commutative operations shouldn't necessarily be commutative--i'd say point+duration->point, but duration+point->undefined--but that may be a bit too strict.)

as a quick rule of thumb, if your code would break if you changed epochs, it's already broken.

kizza• 14 years ago

"Time zones are an integer number of hours away from UTC"

As someone living in +0930, programmers get this wrong way too often - Crittercism gets this wrong, so I don't know when bugs happened in my apps.

Falsehoods Programmers believe about Time

Related Stories