Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Falsehoods programmers believe about time, in a single list

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

  • There are always 24 hours in a day.
  • 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.
  • A week (or a month) always begins and ends in the same year.
  • The machine that a program runs on will always be in the GMT time zone.
  • Ok, that’s not true. But at least the time zone in which a program has to run will never change.
  • Well, surely there will never be a change to the time zone in which a program hast to run in production.
  • The system clock will always be set to the correct local time.
  • The system clock will always be set to a time that is not wildly different from the correct local time.
  • If the system clock is incorrect, it will at least always be off by a consistent number of seconds.
  • The server clock and the client clock will always be set to the same time.
  • The server clock and the client clock will always be set to around the same time.
  • Ok, but the time on the server clock and time on the client clock would never be different by a matter of decades.
  • If the server clock and the client clock are not in synch, they will at least always be out of synch by a consistent number of seconds.
  • The server clock and the client clock will use the same time zone.
  • The system clock will never be set to a time that is in the distant past or the far future.
  • Time has no beginning and no end.
  • One minute on the system clock has exactly the same duration as one minute on any other clock
  • Ok, but the duration of one minute on the system clock will be pretty close to the duration of one minute on most other clocks.
  • Fine, but the duration of one minute on the system clock would never be more than an hour.
  • The smallest unit of time is one second.
  • Ok, one millisecond.
  • It will never be necessary to set the system time to any value other than the correct local time.
  • Ok, testing might require setting the system time to a value other than the correct local time but it will never be necessary to do so in production.
  • Time stamps will always be specified in a commonly-understood format like 1339972628 or 133997262837.
  • Time stamps will always be specified in the same format.
  • Time stamps will always have the same level of precision.
  • A time stamp of sufficient precision can safely be considered unique.
  • A timestamp represents the time that an event actually occurred.
  • Human-readable dates can be specified in universally understood formats such as 05/07/11.
  • The offsets between two time zones will remain constant.
  • OK, historical oddities aside, the offsets between two time zones won’t change in the future.
  • Changes in the offsets between time zones will occur with plenty of advance notice.
  • Daylight saving time happens at the same time every year.
  • Daylight saving time happens at the same time in every time zone.
  • Daylight saving time always adjusts by an hour.
  • Months have either 28, 29, 30, or 31 days.
  • The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.
  • There is only one calendar system in use at one time.
  • There is a leap year every year divisible by 4.
  • Non leap years will never contain a leap day.
  • It will be easy to calculate the duration of x number of hours and minutes from a particular point in time.
  • The same month has the same number of days in it everywhere!
  • Unix time is completely ignorant about anything except seconds.
  • Unix time is the number of seconds since Jan 1st 1970.
  • The day before Saturday is always Friday.
  • Contiguous 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)
  • Two timezones that differ will differ by an integer number of half hours.
  • Okay, quarter hours.
  • Okay, seconds, but it will be a consistent difference if we ignore DST.
  • If you create two date objects right beside each other, they’ll represent the same time. (a fantastic Heisenbug generator)
  • You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.
  • If a process runs for n seconds and then terminates, approximately n seconds will have elapsed on the system clock at the time of termination.
  • Weeks start on Monday.
  • Days begin in the morning.
  • Holidays span an integer number of whole days.
  • The weekend consists of Saturday and Sunday.
  • It’s possible to establish a total ordering on timestamps that is useful outside your system.
  • The local time offset (from UTC) will not change during office hours.
  • Thread.sleep(1000) sleeps for 1000 milliseconds.
  • Thread.sleep(1000) sleeps for >= 1000 milliseconds.
  • There are 60 seconds in every minute.
  • Timestamps always advance monotonically.
  • GMT and UTC are the same timezone.
  • Britain uses GMT.
  • Time always goes forwards.
  • The difference between the current time and one week from the current time is always 7 * 86400 seconds.
  • The difference between two timestamps is an accurate measure of the time that elapsed between them.
  • 24:12:34 is a invalid time.
  • Every integer is a theoretical possible year.
  • If you display a datetime, the displayed time has the same second part as the stored time,
  • Or the same year,
  • But at least the numerical difference between the displayed and stored year will be less than 2.
  • If you have a date in a correct YYYY-MM-DD format, the year consists of four characters.
  • If you merge two dates, by taking the month from the first and the day/year from the second, you get a valid date.
  • But it will work, if both years are leap years
  • If you take a w3c published algorithm for adding durations to dates, it will work in all cases.
  • The standard library supports negative years and years above 10000.
  • Time zones always differ by a whole hour.
  • If you convert a timestamp with millisecond precision to a date time with second precision, you can safely ignore the millisecond fractions.
  • But you can ignore the millisecond fraction, if it is less than 0.5.
  • Two-digit years should be somewhere in the range 1900-2099.
  • If you parse a date time, you can read the numbers character for character, without needing to backtrack.
  • But if you print a date time, you can write the numbers character for character, without needing to backtrack.
  • You will never have to parse a format like ---12Z or P12Y34M56DT78H90M12.345S.
  • There are only 24 time zones.
  • Time zones are always whole hours away from UTC.
  • Daylight Saving Time (DST) starts/ends on the same date everywhere.
  • DST is always an advancement by 1 hour.
  • Reading the client’s clock and comparing to UTC is a good way to determine their timezone.
  • The software stack will/won’t try to automatically adjust for timezone/DST.
  • My software is only used internally/locally, so I don’t have to worry about timezones.
  • My software stack will handle it without me needing to do anything special.
  • I can easily maintain a timezone list myself.
  • All measurements of time on a given clock will occur within the same frame of reference.
  • The fact that a date-based function works now means it will work on any date.
  • Years have 365 or 366 days.
  • Each calendar date is followed by the next in sequence, without skipping.
  • A given date and/or time unambiguously identifies a unique moment.
  • Leap years occur every 4 years.
  • You can determine the time zone from the state/province.
  • You can determine the time zone from the city/town.
  • Time passes at the same speed on top of a mountain and at the bottom of a valley.
  • One hour is as long as the next in all time systems.
  • You can calculate when leap seconds will be added.
  • The precision of the data type returned by a getCurrentTime() function is the same as the precision of that function.
  • Two subsequent calls to a getCurrentTime() function will return distinct results.
  • The second of two subsequent calls to a getCurrentTime() function will return a larger result.
  • The software will never run on a space ship that is orbiting a black hole.
  • Devices will be set to the local timezone
  • Users prefer to use the local timezone

Sources

This list is based on these articles. More detailed information about each statement can be found in one of two articles.

@henke37

This comment has been minimized.

Copy link

@henke37 henke37 commented Jan 29, 2020

Needs cleanup and deduplication.

@blackskye-sx

This comment has been minimized.

Copy link

@blackskye-sx blackskye-sx commented Mar 4, 2020

What time zone are black holes?

@skyvondave

This comment has been minimized.

Copy link

@skyvondave skyvondave commented Apr 6, 2020

What time zone are black holes?

They warp space and time to the point of singularity so the timezone is... infinity?

@Memnarch

This comment has been minimized.

Copy link

@Memnarch Memnarch commented Apr 8, 2020

What time zone are black holes?

They warp space and time to the point of singularity so the timezone is... infinity?

That depends entirely on the distance to it in relation to its mass.

@jcf

This comment has been minimized.

Copy link

@jcf jcf commented Aug 16, 2020

Time zones are a construction to help our society deal with our rotating planet orbiting our star.

To the best of our knowledge, black holes do not support life as we know it so it’s unlikely timezones are relevant to them at all. Same thing for the sun and other stars.

I recommend PBS Spacetime‘s series on black holes as a good intro to the topic.

@karenetheridge

This comment has been minimized.

Copy link

@karenetheridge karenetheridge commented Oct 21, 2020

Timezones are useful constructs for converting between a "universal" time and a "local" time. When orbiting a black hole, there very much is a local time, so it would be reasonable to have a timezone to represent times in that location. However, the rules for converting between the local and universal time require algorithms that we cannot yet represent with any current standards such as the Olson Timezone format and would require a whole new round of RFCs, and by the time those passed IETF review the black hole likely will have already collapsed.

@UTSAV-DEEP

This comment has been minimized.

Copy link

@UTSAV-DEEP UTSAV-DEEP commented Nov 5, 2020

Leave black hole aside for a moment, what timezone to use for exact north pole and south pole of Earth itself?

@karenetheridge

This comment has been minimized.

Copy link

@karenetheridge karenetheridge commented Nov 5, 2020

No one lives there, so there is no need for a standard timezone in those locations. Usually scientific expeditions use the timezone of their home base.

@mbrooks

This comment has been minimized.

Copy link

@mbrooks mbrooks commented Mar 7, 2021

Also don't assume time is consistent between planets. A day on mars is 24h and 37m. A year on mars is 687 days.

@Memnarch

This comment has been minimized.

Copy link

@Memnarch Memnarch commented Mar 8, 2021

Also don't assume time is consistent between planets. A day on mars is 24h and 37m. A year on mars is 687 days.

You'd probably want to measure in seconds since X (like unix timestamp) and convert it to the planets local time frames.

@AdamWhiteHat

This comment has been minimized.

Copy link

@AdamWhiteHat AdamWhiteHat commented Apr 19, 2021

What time zone are black holes?

NaN

Edit:
A time zone describes a region or location in space.

Using the 3+1 dimension geometry of space-time, one can convince oneself that inside a black hole, the roles of space and time are swapped.

So the question becomes not 'Where (in space) is the time zone black holes are located' but 'When (in time) is the time zone black holes are located'.

So what is the answer? Well, I'm not certain, but you'll be glad to know that I've sent a scout into the middle of one to find out, and I'll let you know just as soon as it returns... (This may take a bit.)

In the interim though, I could hazard a guess: I have a hunch the answer is either +∞, or 42. Whatever the case, I have proven mathematically that it absolutely, positively cannot be 2. Extending the same logic, I can tell you its looking rather unlikely that it'll be 4 as well.

@Lucretiel

This comment has been minimized.

Copy link

@Lucretiel Lucretiel commented Jun 4, 2021

"A particular time stamp is valid in all time zones"

Counterexample: because leap seconds are simultaneous worldwide, the time stamp that includes such a leap second is only valid in the original time zone. For instance, 2005-12-21T18:59:60 is a valid only in EST.

@Memnarch

This comment has been minimized.

Copy link

@Memnarch Memnarch commented Jun 10, 2021

"A particular time stamp is valid in all time zones"

Counterexample: because leap seconds are simultaneous worldwide, the time stamp that includes such a leap second is only valid in the original time zone. For instance, 2005-12-21T18:59:60 is a valid only in EST.

Isn't a leap second usually stretched across the day, and therefore doesn't actually show up in a timestamp?

@jotoho

This comment has been minimized.

Copy link

@jotoho jotoho commented Jun 10, 2021

Isn't a leap second usually stretched across the day, and therefore doesn't actually show up in a timestamp?

I heard that some companies like Google do that because of their important/sensitive infrastructure but (as far as I know) that's not the norm. So the rest of the world still has that extra second in the timestamp.

@Memnarch

This comment has been minimized.

Copy link

@Memnarch Memnarch commented Jun 10, 2021

Isn't a leap second usually stretched across the day, and therefore doesn't actually show up in a timestamp?

I heard that some companies like Google do that because of their important/sensitive infrastructure but (as far as I know) that's not the norm. So the rest of the world still has that extra second in the timestamp.

It seems for unix-timestamps it is the norm:
https://stackoverflow.com/questions/16539436/unix-time-and-leap-seconds
EDIT: Or maybe not...oh the joy of time
EDIT2: or is it?
https://en.wikipedia.org/wiki/Unix_time

@ForestMars

This comment has been minimized.

Copy link

@ForestMars ForestMars commented Jun 28, 2021

@Memnarch - It has to be. Unix time has no conception of leap seconds, and every day always has the same number of seconds (which is of course, a falsehood programmers believe about time.) So the standard handling is for the leap second to have the same epoch label as the second which preceded it. Which obviously can not lead to any bugs.

@Memnarch

This comment has been minimized.

Copy link

@Memnarch Memnarch commented Jun 29, 2021

@ForestMars why should it? :P But thanks for the info. That explains why google stretches them across the day.

@anomaly256

This comment has been minimized.

Copy link

@anomaly256 anomaly256 commented Aug 30, 2021

To the best of our knowledge, black holes do not support life as we know it so it’s unlikely timezones are relevant to them at all. Same thing for the sun and other stars.

  • That blackholes do not support life and therefore time zones do not apply to them
  • That stars also do not support life and therefore time zones do not apply to them
@AdamWhiteHat

This comment has been minimized.

Copy link

@AdamWhiteHat AdamWhiteHat commented Sep 2, 2021

Also don't assume time is consistent between planets. A day on mars is 24h and 37m. A year on mars is 687 days.

687 days? Now is that Earth days? Mars days? Egads man, three sentences in and you are already making the same sorts of errors you were lamenting about in the first sentence.

Also, if you use Mars based units, you can just say that a day is equal to 1. This is not only a much simpler expression, its a fair bit more accurate as well.

@RedyAu

This comment has been minimized.

Copy link

@RedyAu RedyAu commented Sep 4, 2021

Oh boy, when mars time will have to be in all software, how fun that will be!
Also, I think that we should stick to "sol" or "martian day" and never say "day" for a sol on Mars, to avoid confusion.

@karenetheridge

This comment has been minimized.

Copy link

@karenetheridge karenetheridge commented Sep 5, 2021

These are some notes on how time might be told on Mars, courtesy of Robert L. Forward in "Martian Rainbow": https://ops-alaska.com/time/forward/forward.htm

And this is the appendix from the first book in David Weber's Honor Harrington series, explaining the calculations involved from converting from Terran days and years to the various local calendars: https://www.baen.com/chapters/basilisk_a.htm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment