Falsehoods programmers believe about time, in a single list

falsehoods-programming-time-list.md

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.

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

Principle 11: No time exist for complaints about AI

I just ran into a fun one:

The server clock and the server clock will always be set to (roughly) the same time.

I had multiple servers, each timestamping events that got stored in a shared database. This led to significant confusion until I fixed NTP on the servers...

Obligatory: "Time is a flat circle"

https://www.youtube.com/watch?v=0mhZBLUyybo

If anyone ever needs to do anything for Target2 Securities - that one breaks half the list and then some. The calendar/clock time/event any given business system operates in may or may not have any deterministic connection to world clock/calendar. Assuption, that the system even has at a given time a valid date-time is also incorrect. The days start when the system says they start, IF they start at all. One day can start under normal operation up to FOUR days ahead. A day can end and next one may not start for 3 more days, days are skipped based on a calendar agreed at start of year and the settlement timestamp has nothing to do with when it actually happened. Oh, and within one up to 4 days long day, there is no deterministic way of ordering what happened first...

one more falsehood. NTP will solve timing issues on my distributed systems.

These are all interesting points, and it really bugs me that each point doesn't have an associated link I can follow to learn more about it. Cite your sources dammit!

… it really bugs me that each point doesn't have an associated link I can follow to learn more about it. Cite your sources dammit!

Good point, but you see, the purpose of falsehood lists has never been to learn or to improve the state of affairs:
https://kevin.deldycke.com/2016/12/falsehoods-programmers-believe-about-falsehoods-lists/

Other false beliefs:

• It's the same year in every country (what about New Year?)
• At least the year in two countries can only differ by one (it's the year 2566 now in Thailand)
• every country uses the Gregorian calendar
• second is the same everywhere (there are differences because of the General Relativity and time zones that account for these differences, for example, Barycentric Coordinate Time and Geocentric Coordinate Time)

See also: https://alexwlchan.net/2019/falsehoods-programmers-believe-about-unix-time/

https://www.youtube.com/watch?v=IlRTcIK1aGo is a great talk on this subject as well

And, of course, there's now a relevant XKCD on the subject.

Add to the list:

• Midnight will always have an AM at the end of a 12h time string.
• Ok, but at least there consistently is a time hh:mm:ss at midnight and it wont just be a date randomly.

Thank you windows pocket on a Siemens HMI.

Okay @rolfbjarne I need examples, those sound delicious

For the daylight saving time starting and ending in different years case, think Australia (https://en.wikipedia.org/wiki/Daylight_saving_time_in_Australia)

The day before Saturday is always Friday.

Anyone can explain this?

@muriloazevedo https://www.nytimes.com/2011/12/30/world/asia/samoa-to-skip-friday-and-switch-time-zones.html

• The Y38K problem doesn't exist

The leap year is not only every 4 years, if the year is divisible by 100, the leap year happens every 400 years. 2100 for example, wont be a leap year.
https://en.wikipedia.org/wiki/Century_leap_year

This is my new favorite picture to share with everyone - UTC +13! 🤯

timezones in Antarctica

• No software will ever have to handle non-Earth days (e.g. Martian Sols)
• Well, no software will ever have to handle non-Earth days and Earth days together. (e.g. the Mars Relay Network)
• Speed-of-light delay is always negligible (e.g. when synchronizing to GPS atomic clocks)
• Atomic clocks keep perfect time (e.g. even NIST-F2 has a relative uncertainty value)
• Durations expressed as integers will always be measured in seconds (e.g. nanoseconds)
• Well, some SI multiple of a second (e.g. ncurses.h's halfdelay(int) uses tenths of a second)
• Well, some power of ten multiple of a second (having trouble finding a good example, but I'm certain I've seen half-seconds used somewhere)
• Durations expressed as negative integers will always have a consistent meaning (e.g. ncurses.h's timeout(int) uses negative numbers to indicate a blocking read, but it also commonly means a second event occurred before a first)
• No software will ever deliberately mishandle dates (e.g. Lotus 1-2-3 bug)
• No software will ever deliberately mishandle timers (e.g. Spectre mitigation in web browsers)
• Nobody will ever want to compare dates more than a hundred years apart (I mean, duh)
• We know the length of every historical year (e.g. the pre-Julian-reform Roman calendar)
• Displays will refresh at integer frequencies (e.g. NTSC video is 29.97 frames per second)
• Displays will refresh at consistent frequencies (It's a clock, it's going to slip)
• Two signals with the same clock rate will be synchronized (e.g. analog video compositing)
• Two synchronized signals with the same clock rate will stay synchronized (e.g. turn signals)

The leap year is not only every 4 years, if the year is divisible by 100, the leap year happens every 400 years. 2100 for example, wont be a leap year. https://en.wikipedia.org/wiki/Century_leap_year

@pierreinglebert

True, but only until further notice. This method isn't exact and will eventually run out of sync with the earth/sun system by a sufficient amount that'll make corrections or changes necessary.

White House wants Moon to have its own time zone

• There are always 52 weeks in a year.

• It is reasonable to use the same time/date output to all users of a system.

Encountered in a database that was serving the office admin side of a company, for which the inclusion of anything more precise than minutes required constant scrubbing of the data so that it didn't look insane when generating communication for other companies in a human-focused business context, the large-scale machine side, which needed seconds because the programming that ran some of the machines would crash if that was not provided, and the data-documentation side, which needed milliseconds because of data reporting requirements to clients' technical sides. All of which needed to be human-readable at least part of the time (not just used internally by the software).

I was working on the admin side and became an absolute HERO for being able to code an Excel function that would for-our-purposes-reliably scrub the extra fields from times and reformat the dates to the user's choice of DD-MM-YYYY or MM-DD-YYYY. Which I heavily commented in case the company ever expanded to areas for which other formats were needed. Previously, they had been manually going through and trying to do that, which wasted a lot of administrative time. Thankfully, I didn't need to properly "handle" time, just format a particular very consistent format of input into another format, and it still made me nervous given why I was writing the function.

• The system clock timestamp will always advance at one second per second.
• Ok, well it will always advance at the same rate, close to one second per second.
• The system clock will always be monotonically increasing at a constant rate.
• ...well, at least it's always returning numerically increasing timestamps.

Some fun ones from the world of video games:

• Adding the same amount of time periods N times will result in the same time as if adding the product of the time periods.
• The time elapsed since the last clock tick is always the same.
• Okay, but adding up the elapsed times between clock ticks will give a consistent result.
• I can repeatedly schedule an event N time units in the future and it will result in the event happening every N time units.
• Okay, but a timer set to fire every N time units will fire every N time units.
• Countdowns always run at the same speed.
• If something is labeled as "seconds", it means the SI standard unit of a second.
• Okay, but at least it isn't twice as fast as a SI second.
• Displayed times accurately correspond to real time, whatever time unit they happen to use.

One which I think is missing from the list: "The day after Friday is always Saturday".

The day before Saturday is always Friday.

the list inverted it, but it's there :)