
Falsehoods Programmers believe about Time - mcfunley
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
======
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.

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

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

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

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

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

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

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

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

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

In the British Empire, anyway.

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

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

~~~
fusiongyro
> Unix time is completely ignorant about anything except seconds.

In hindsight, it seems like a brilliant decision.

~~~
Arelius
But then we had to go and make it care about leap seconds...

------
endlessvoid94
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...](http://algeri-wong.com/yishan/great-unsolved-problems-in-computer-
science.html)

TL;DR: calendaring is hard. really hard.

------
tomjen3
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
That will stress it a bit, but to really torture it, see if it accepts 2012
June 30 23:59:60

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

~~~
obtu
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/>

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

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

~~~
adavies42
> 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

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

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

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

~~~
sk5t
The '100ns ticks' example is actually the Windows FILETIME, not my own
invention. ISO 8601 is fine and dandy for stringified datetimes, although it's
my position that strings open the door to more errors when consumed or
produced by lazy/poor programmers.

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

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

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

~~~
edanm
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_...](http://en.wikipedia.org/wiki/Jewish_calendar#Measurement_of_hours).

------
ColinWright
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
So, were you on the Concorde, or was it a Tu-144?

~~~
gregholmberg
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)>

~~~
jeroen94704
Cool! So you could find a spot somewhere up north where you can take a stroll
and experience an eternal sunrise/sunset. Very romantic :)

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

------
cpeterso
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...](https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture)

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

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

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

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

~~~
sp332
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
A bad test might boil down to,

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

then fail from time to time.

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

~~~
BrandonM
_> "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.

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

~~~
mooism2
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?)

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

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

------
hcarvalhoalves
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...](http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/Date.html#Date\(\))

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

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

------
arohner
36\. GMT and UTC are the same timezone.

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

------
Florin_Andrei
> _32\. A time stamp of sufficient precision can safely be considered unique._

I'm so guilty of that one.

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

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

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

~~~
jes5199
I think every test suite has tests that only fail right around the start and
end of daylight savings time.

~~~
NoahSussman
If the tests are failing because the production code is confused about
daylight savings time, then you may have a serious problem.

If on the other hand it's just the test code that's flaky, usually such
problems can be alleviated by refactoring such that one passes the time
function as a parameter. This is in preference to hard-coding calls to the
system time in test, which imho one should never do.

Once an arbitrary time function can be passed as a parameter, one can provide
a mock or fake system clock for test purposes. Ideally one would still want to
test under daylight savings' conditions. But at the least this approach leaves
one in a place where one can test the common 24-hours-in-a-day case without
having the tests spuriously fail two days out of every year.

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

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

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

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

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

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

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

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

~~~
mbrubeck
Also leap seconds: <https://en.wikipedia.org/wiki/Leap_second>

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

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

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

------
apaprocki
39\. The next day after 3 Sep 1752 is 4 Sep 1752.

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

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

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

------
cpeterso
Also, time is unidirectional.

~~~
tomjen3
Well time would be unidirectional, right?

The computer clock might not be.

~~~
zanny
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)

~~~
mooism2
If you are moving faster than the speed of light, our understanding of physics
is wrong and we can't make any sensible predictions.

------
uvTwitch
"This will only take a few minutes."

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

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

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

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

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

~~~
TazeTSchnitzel
So what does make use then?

------
crisnoble
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
<http://xkcd.com/927/>

------
Shenglong
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
Not just "some places" go backwards. UTC itself can jump backwards during a
leap second.

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

------
bluesmoon
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...](http://stackoverflow.com/questions/11023086/how-do-i-interpret-
these-strange-javascript-timestamps-from-mobile-phones)

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

------
jhawk28
He missed the myth that "Time always moves forward"

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

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

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

~~~
MarkMc
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)

~~~
rmc
_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.

~~~
MarkMc
Hmm...I did not know that! I should really have said 'eg.' instead of 'ie.'

The point of the above 'timestamp' is is to represent a specific instant in
time, independent of any time zone or calendar system. You can use Unix time
for this purpose.

~~~
rmc
Depends. unixtime is for seconds, if you want to record 2 things that happen ¼
second apart, they might have the same value.

Also during leapseconds, unix time does funny things, like 2 second long
'seconds'. or it goes backwards to reset etc.

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

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

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

~~~
estel
What about ISO 8601? <http://en.wikipedia.org/wiki/ISO_8601>

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

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

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

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

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

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

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

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

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

------
efnx
What about time can you depend on?

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

~~~
efnx
Exactly.

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

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

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

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

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

~~~
user49598
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>

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

------
michaelochurch
Thread.sleep(1000) sleeps for 1000 milliseconds.

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

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

