https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca

Skip to content
 
[                    ]
All gists Back to GitHub Sign in Sign up
 
Sign in Sign up
{{ message }}

Instantly share code, notes, and snippets.

@timvisee

timvisee/falsehoods-programming-time-list.md

Last active Aug 22, 2022

  * Star 739
  * Fork 27

Star
Code Revisions 3 Stars 739 Forks 27
Embed
What would you like to do?
">Embed Embed this gist in your website.
Share Copy sharable link for this gist.
Clone via HTTPS Clone with Git or checkout with SVN using the
repository's web address.
 
Learn more about clone URLs
[<script src="https:/]
 
Download ZIP
Falsehoods programmers believe about time, in a single list
Raw
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

Load earlier comments...
@Memnarch
Copy link

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.

Sorry, something went wrong.

@AdamWhiteHat
Copy link

AdamWhiteHat commented Apr 19, 2021 *
edited

    What time zone are black holes?

[DEL:NaN:DEL]

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.

Sorry, something went wrong.

@Lucretiel
Copy link

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.

Sorry, something went wrong.

@Memnarch
Copy link

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?

Sorry, something went wrong.

@jotoho
Copy link

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.

Sorry, something went wrong.

@Memnarch
Copy link

Memnarch commented Jun 10, 2021 *
edited

        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

Sorry, something went wrong.

@ForestMars
Copy link

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.

Sorry, something went wrong.

@Memnarch
Copy link

Memnarch commented Jun 29, 2021

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

Sorry, something went wrong.

@anomaly256
Copy link

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

Sorry, something went wrong.

@AdamWhiteHat
Copy link

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.

Sorry, something went wrong.

@RedyAu
Copy link

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.

Sorry, something went wrong.

@karenetheridge
Copy link

karenetheridge commented Sep 5, 2021 *
edited

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

Sorry, something went wrong.

@Quicksilver151
Copy link

Quicksilver151 commented Nov 12, 2021

HELP one of my friend's birthday is on February 30th
so his age is having a hard time registering in my program
anyone know a quick fix?

Sorry, something went wrong.

@jotoho
Copy link

jotoho commented Nov 12, 2021

@Quicksilver151 I think, this is very much not an appropriate place
to ask for programming help. You also gave far too little information
for anyone to give you detailed instructions. Try somewhere else.

Sorry, something went wrong.

@Quicksilver151
Copy link

Quicksilver151 commented Nov 12, 2021

@jotoho
r/whoooosh?

Sorry, something went wrong.

@mlliarm
Copy link

mlliarm commented Dec 23, 2021

    Time has no beginning and no end.

As far as I know, there was no time before the Big bang.

Sorry, something went wrong.

@mlliarm
Copy link

mlliarm commented Dec 23, 2021

@Quicksilver151 LOL.

Sorry, something went wrong.

@philihp
Copy link

philihp commented Jan 19, 2022

Similar to "The machine that a program runs on will always be in the
GMT time zone" is:

  * The device that a program runs on will be set to the local time
    zone.

For a few years on Facebook's iOS app in events, they would print the
timezone of the device adjacent to an event time in the local time of
the event. So they would say a party in New York starts at 6:30pm
GMT, when they actually meant either the party starts at 6:30pm EST
or the party starts at 11:30pm UTC.

Sorry, something went wrong.

@Memnarch
Copy link

Memnarch commented Jan 24, 2022

@mlliarm that's why it's listed under "Falsehood" ;)

Sorry, something went wrong.

@mlliarm
Copy link

mlliarm commented Jan 24, 2022

@Memnarch oh, ok xD

Sorry, something went wrong.

@EpicScizor
Copy link

EpicScizor commented Feb 2, 2022

Myth: DST starts/ends at 2am.

Or midnight, as the case may be,

Sorry, something went wrong.

@javiershaka
Copy link

javiershaka commented Feb 16, 2022

now what.jpg meme

Sorry, something went wrong.

@cricrazy
Copy link

cricrazy commented Feb 18, 2022

I bet, Christopher Nolan can make a movie on every single of these
Time falsehood list.

Sorry, something went wrong.

@cben
Copy link

cben commented May 3, 2022

Example for "The day before Saturday is always Friday." being false:

https://www.timeanddate.com/news/time/samoa-dateline.html

    The change will occur at midnight on December 29, 2011, taking
    the Pacific island nation straight into December 31, 2011.

which also jumped them from Thursday straight into Saturday --
shifting their weekdays was the motivation for this change:

    "In doing business with New Zealand and Australia, we're losing
    out on two working days a week,"

Sorry, something went wrong.

@Luxter77
Copy link

Luxter77 commented May 21, 2022 *
edited

Isn't the earth but a spaceship orbiting (the sun and) the center of
our galaxy: Sagittarius A*, a supermassive black hole.

Sorry, something went wrong.

@mitchellwyle
Copy link

mitchellwyle commented Jul 12, 2022

There are other falsehoods associated with temps atomique
international,, aka International Atomic Time, including its
attosecond accuracy. TAI was invented by a now-defunct french
government body that called its members "time lords" and a decent
Unix implementation of which is here.

Sorry, something went wrong.

@wjt
Copy link

wjt commented Aug 22, 2022 *
edited

"Britain uses GMT in winter, so the Unix epoch occurred at midnight
in Britain." I made this assumption in a test case once!

Sorry, something went wrong.

@felixfischer
Copy link

felixfischer commented Aug 22, 2022

Another falsehood I used to believe: Easter in any given year is on
the same weekend in all countries that celebrate it.

Sorry, something went wrong.

@uclaeamsavino
Copy link

uclaeamsavino commented Aug 22, 2022 *
edited

Falsehood that I've seen in code: Arizona doesn't observe Daylight
Savings Time. The Navajo Nation in the Four Corners area does observe
Daylight Savings Time.

Sorry, something went wrong.

@kevinb9n
Copy link

kevinb9n commented Aug 22, 2022 *
edited

Another falsehood: "midnight" is a time that exists for every day.

(Asia/Gaza is an example of a time zone that does its spring DST
change "at midnight" so to speak, but that means that the time
changes directly from 23:59:59.999... to 01:00:00.000, so ironically
the time we call "midnight" never happened.)

Sorry, something went wrong.

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

Footer

 (c) 2022 GitHub, Inc.

Footer navigation

  * Terms
  * Privacy
  * Security
  * Status
  * Docs
  * Contact GitHub
  * Pricing
  * API
  * Training
  * Blog
  * About

You can't perform that action at this time.
You signed in with another tab or window. Reload to refresh your
session. You signed out in another tab or window. Reload to refresh
your session.