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

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