11 ms·

Falsehoods Programmers Believe About Time (2012)

183 points by kushti 10y ago

GauntletWizard 10y ago
Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash. Make it loud and clear that something is wrong. Any attempts to rectify the problem, and most attempts to even detect it will only add surface area to the code, surface area where you can screw up and introduce bugs. Could the system's timezone change? Yes. If you're manipulating time sanely, you're already using a timezone aware time class - particularly when serializing - and that's great. But if you're uncertain, it's best not to try to rectify. Your program will never be able to guess with any success. Almost all of this post strikes me as along the vein of the questions of Babbage - "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" Almost all of these are the wrong numbers. Rather than leading you to the simple, correct solution (Use good serialization formats and timezone aware datastructures) it leads you down a path of paranoia, convinced the world is out to get you. If you're programming for that world, you're either a DRM programmer and should burn in hell, or you're doing it wrong. Trust your environment and OS and make damn sure that when you're setting up those layers you set them up right - Don't worry that every second open() call will return an invalid filehandle, just because.
- Rapzid 10y ago
  Yes. To further play devil's advocate; a lot of times it's better to just write time handling in a naive manner. Even if you know it will fail under certain circumstances, the program might not need to always be correct to be successful. I HATE writing stuff like this, but sometimes the ROI is just not there.
- kingcong5 10y ago
  Yeah, same thing I was thinking. Being exact in time can drive you crazy. Don't run yourself in the ground.
- kasparsklavins 10y ago
  There are situations in which it is not acceptable to make a "loud crash", e.g., while a plane is flying. There was a quote by a nasa engineer that an incorrect action is better than no action at all, but I cant find it at the moment.
  - gpderetta 10y ago
    I'm pretty sure that if a flight computer detects an inconsistency, it will immediately reboot, and not try to limp along in a bad state. Either the reboot is fast enough to recover quickly enough, or the redundant systems will take over.
- yoo1I 10y ago
  No. Yesterday my friends Mac crashed hard while they were working on a foolishly unsaved one-and-a-half page document in LibreOffice. At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" . Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working. This "attempt to rectify" the problem, could only have made things better not worse, so that's reasonable to implement. I am not saying that every problem needs a solution like this. But blanket statements like "crash whenever there is a problem with your environment", while certainly the correct way to do it in some cases, leads to software that's really shitty use if that's all the software does. Because while > Almost all of these are the wrong numbers. is correct from a programmers point of view, we aren't talking about the numbers a user put in, but rather numbers that the user has no control about. And not many things are more annoying than computers doing unexpected things for reasons that are incomprehensible to you.
  - elmigranto 10y ago
    I don't think parent comment meant ditching swap files in text editors or reboot on GPS errors in plane's autopilot. Just sort out upfront where the value is (user data, safety and reliability, rendering fast, etc…) and set requirements appropriately. There is no reason to handle leap seconds in a flappy bird game, or fork your database server to implement "proper" time handling with historically correct time zones and all the appropriate conversions between them, if you are writing a Twitter client.
  - gpderetta 10y ago
    >At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" . > Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working. Uh, that's exactly what the OP was advocating, if I understand correctly. On a consistency check failure (i.e. an assert), crash immediately [1]. If the application correctly handle transactional state changes, it will be able to recover on startup from the replay log, as all changes are immediately persisted on the log. This approach is known as "Crash Only Software", and it is pretty much the only approach for writing robust applications. [1] Syncing the replay log to stable storage can be a good thing though.
- fauigerzigerk 10y ago
  >Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash. When it comes to time, a crash is not the most likely outcome of not thinking about what could happen. More likely your code will stall or do the wrong thing. Think about polling, pinging other systems or rate limiting. At the end of daylight savings time your code could easily stall for an hour or DDOS another system because rate limiting fails.
Animats 10y ago
Leap seconds are a big enough problem that stock markets shut down for them.[1] Google starts advancing their clocks hours in advance of a leap second. Power companies take about four hours to catch up after one. (Every 1800 RPM generator has to make 30 extra turns.) Very few systems properly handle a 61-second minute. Unix timestamps are fundamentally incompatible with leap seconds. [1] http://money.cnn.com/2015/06/29/technology/leap-second/ http://money.cnn.com/2015/06/29/technology/leap-second/
- elmigranto 10y ago
  Sure is a problem when you are writing a system for processing stocks, not really if you are making a calendar app or ecommerce website. I guess what I mean is that things like that are a nice piece of trivia, little fun facts, but nothing to be concerned of for most of us.
  - aardvark179 10y ago
    Until you assume midnight one day plus 24 * 3600 seconds will equal midnight the next day. These kinds of problems will bite you in all sort of places you don't think you need to worry about them.
- sparky_z 10y ago
  "Every 1800 RPM generator has to make 30 extra turns." I'm having trouble wrapping my my head around this one. If the goal is maintaining a steady output, shouldn't they keep revolving at the same rate, without worrying about what day the "current" second (no pun intended) belongs to? After all, I'm assuming they don't "catch up" after leap days, they just run for an extra day at the same output level. Why would leap seconds be different? Put another way, what do they need to spread those extra 30 turns over a 4 hour catch up period? Weren't they given an extra second in which to take care of them?
  - XorNot 10y ago
    The power grid doesn't work if disparate phases aren't synchronized. On a very large scale this is why HVDC is used, but on smaller scales its still more cost-effective to coordinate with GPS time since it's atomic-clock backed.
inlined 10y ago
My favorite time-related false beliefs are about time zones: 1. 1AM happens 24 times a day 2. Ok, so 1A is screwed up because of DST. Noon happens 24 times a day. 3. The maximum distance between time zones is 24 hrs 4. Time zones are in 1hr increments 5. In half hour increments? 6. UTC offset is a good thing to store in someone's profile 7. People live in a fixed number of UTC offsets
- jaggederest 10y ago
  Add to it: Time zones change linearly from east to west and west to east For each physical location there is exactly one time zone
  - inimino 10y ago
    And: The time zone you use is a matter of geography, not political affiliation.
    - TeMPOraL 10y ago
      Understanding that point suddenly makes half of the list much more obvious.
  - plopilop 10y ago
    You can also add: * One geographical location won't change its timezone over time * Apart from DST, one geographical location won't change its timezone over time * If a location changes timezone, the leap is always less than an hour, maybe a few hours * Ok, less than a day * Why are you talking about 2011, December 30th in Samoa Islands?
  - 77pt77 10y ago
    > For each physical location there is exactly one time zone Care to elaborate?
    - Crespyl 10y ago
      I don't know of any parcels of land that are simultaneously in more than one zone, but I do know that (until recently?) Indiana used to change time zones from Eastern to Central instead of using DST.
calanya 10y ago
That the clock always moves forward. As one example, some clocks are cpu specific (rather than system specific). When a thread gets scheduled to a different cpu, it might be talking to a different clock, and getting a backwards time. The user might also be changing the clock while the program is running, of course. If the forward direction of time is important, make sure the the source of time is a monotonic clock API.
- saretired 10y ago
  All I can add is a warning about running NTP if you are maintaining a priority queue of time-stamped actions (now + delta, where delta depends on the action): use CLOCK_MONOTONIC instead of wall time.
po1nter 10y ago
This is a very interesting video by Computerphile on this subject: https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
mofle 10y ago
More interesting falsehoods in this awesome list: https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood
- dredmorbius 10y ago
  Nice. Includes the one I'd just posted as well. I recommend submitting that to HN. Looks as if it was a couple of months ago, but definitely worth the resubmission as it didn't take: https://hn.algolia.com/?query=https:%2F%2Fgithub.com%2Fkdeldycke%2Fawesome-falsehood&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=https:%2F%2Fgithub.com%2Fkdeld...
rdtsc 10y ago
I got two I noticed over the years: * Didn't think about time at all. In most cases most don't think about time until it becomes a problem. It often ends up with a system which behaves in surprising ways, and is the equivalent to the developer believing any of those things in the article. But there is a difference in them believing those falsehoods, and simply not being a aware of them at all. * Time moves forward This is probably the biggest gotcha of all. Just imagine how many times int the past you did dt = now() - t0, then did something with dt like sleep(dt). Well time will move backwards sometimes and dt is negative. I bet this will make most people here worried and they'll think about code they wrote like that (sure did). I have seen systems freeze for example because they end up sleeping for a huge amount of time (negative number was cast to an unsigned huge number). A small advice on how to improve errors related to time is to abstract it away from algorithms and code as much as possible. Instead of always calling gettimeofday() / time() / now() function to get the current time, in a piece of lower level code, try to pass it in as an argument. That will make code testable. I have seen fun failing test cases. Something like encoding the current time the test was written and a dt to current time. The test was working for years then started failing eventually because of the hard coded time.
- baq 10y ago
  > * Time moves forward I agree. Smart library developers seem to agree, too. Example from Python docs: https://docs.python.org/3/library/time.html#time.monotonic https://docs.python.org/3/library/time.html#time.monotonic The only (cough) problem is drilling this knowledge into developers' heads - and as you said, awareness that there even is a problem!
- Iv 10y ago
  > (negative number was cast to an unsigned huge number) Slightly off-topic pet-peeve of mine: never used unsigned, unless you have an extremely good reason for it. Saving one bit is not one of them. You never know when you will need to do arithmetic on your unsigned values. Time going backwards is a good example of this.
  - __s 10y ago
    This crops up in Rust's std::time::Duration which has no concept of negative duration
okket 10y ago
Previous discussion: https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208 (4 years ago, 213 comments)
amelius 10y ago
Falsehood non-physicists believe about time: simultaneity. https://www.youtube.com/watch?v=wteiuxyqtoM https://www.youtube.com/watch?v=wteiuxyqtoM
MarkMc 10y ago
My experience is that for most applications, programmers really only need to understand 3 types: 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. 2. A date in the Gregorian calendar. This could also be an integer offset from a particular day, but it's better to encapsulate it in a class that allows you to add days or months, get the number of days between two dates, etc. 3. A timezone which is necessary to convert between the two types mentioned above. Java has default classes to represent Types 1 and 3, but is missing a simple class for Type 2. So I designed one myself: http://calendardate.sourceforge.net http://calendardate.sourceforge.net
- zAy0LfpBZLC8mAC 10y ago
  > 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. That's already an undefined statement ;-) I mean, I guess you are actually aware of it, but that's not actually an instant in time, that's about 24 different spans of time, each 86400000 milliseconds long.
  - inimino 10y ago
    It took me a while to figure out what you are pointing out. GP left out the time and timezone, but we still recognize that date as shorthand referring to the Unix epoch.
  - MarkMc 10y ago
    Whoops sorry I should have said January 1,1970 GMT!
- dlubarov 10y ago
  Did you see Java 8's java.time classes? There's LocalDateTime for type 2, and Instant which is like a much improved Date. Both obviously Joda inspired.
  - MarkMc 10y ago
    Thanks - I didn't know Java 8 had incorporated Joda time. Actually LocalDate is a better representation for Type 2 because it doesn't encapsulate minutes, hours or seconds. This would make it ideal to represent "John's birthday" or "date on which the customer repaid loan". In fact, I'm disappointed that Java has incorporated Joda time - new Java programmers will now need to crawl over a huge pile of time-based classes to pick out the ones they need, when for 99% of cases only the same 3 types are necessary. How many of these novice users will incorrectly use LocalDateTime to represent Type 1?
partycoder 10y ago
Dates and times, floating point numbers, even strings... there will be always magic in how data is represented/encoded. Now in the case of dates, there's the epoch, and a precision determined in terms of that epoch, there are compatibility workarounds between 32-bit and 64-bit time... we add have leap days and leap seconds, and of course: the fact that clocks go out of sync, timezones and daylight saving time, as well as a long long list of things. Some countries move dates for DST every year. Then, there are days that "do not exist" (September 1752 in UK/US, etc, when they moved from the julian to the gregorian calendar).
Arnt 10y ago
Time education in practice: The linux kernel boots 5 minutes before the end of time, so that anyone whose code would break when jiffies wraparound will see that breakage soon after boot. That's a great, great feature.
- fbender 10y ago
  Care to elaborate on that?
  - Arnt 10y ago
    The linux kernel's basic time unit is the jiffy, which wraps around every ~497 days and is visible to userspace using clock_gettime(CLOCK_MONOTONIC). In order to make sure that bugs don't occur only after 497 days, the jiffy value doesn't start at 0. Rather, the boot-time value is such that the jiffy value will wrap around after five minutes. One of my brothers worked for an embedded device manufacturer that got bitten. The software worked great unless it was started in the first five minutes after a reboot. But since booting and waiting five minutes is easy, the fix was, too. The nonzero boot-time value made it simple to fix a bug that occurs every 497 days. Fantastic, say I.
    - Klathmon 10y ago
      What a great solution! It's a "hostile" move that probably ends up preventing countless bugs in high-uptime systems.
    - carterehsmith 10y ago
      Ha, looks like they did not fix the bug? That is, they did not account for wraparound, they just avoided it. Is that correct?
      - Arnt 10y ago
        Where my brother worked, you mean? They ensured that their software measured speed correctly in the hosts's fifth minute of uptime, and in all other minutes too.
saittam 10y ago
And because time is so simple, we figured to just rely on accurate time for TLS certificate validation and thus the security of HTTPS. </sarcasm>
dredmorbius 10y ago
We could just cut to the chase: Falsehoods programmers believe: https://encrypted.google.com/search?hl=en&q=%22things%20programmers%20believe%20about%22#hl=en&q=falsehoods+programmers+believe+about+names&search_plus_one=form https://encrypted.google.com/search?hl=en&q=%22things%20prog... http://www.metafilter.com/117073/Falsehoods-Programmers-Believe http://www.metafilter.com/117073/Falsehoods-Programmers-Beli... By way of lists, a pretty comprehensive one: http://spaceninja.com/2015/12/08/falsehoods-programmers-believe/ http://spaceninja.com/2015/12/08/falsehoods-programmers-beli... More in another comment: https://news.ycombinator.com/item?id=12675830 https://news.ycombinator.com/item?id=12675830
- rurban 10y ago
  I miss falsehoods about pathnames: * That there's never a \0 in a pathname wchar names on MSWin UNICODE and WinCE. Symbian uses UTF16. * That paths are seperated by / Yes, Windows NT accepts /, VMS, VOS, RISC OS also, but MacOS classic had :, and VMS uses []. And there are still \ pathseps only, like DOS, OS/2, SYMBIAN, Novell NETWARE, AmigaOS4. Native Acorn RISC OS uses . as pathsep and : as in DOS. Just the easiest ones.
  - Bouncingsoul1 10y ago
    "* That paths are seperated by /" The day I learnded that Korean Windows version uses a Won sign and Japanes use a Yen sign was very bad day.
  - vidarh 10y ago
    AmigaOS paths are separated with "/" between directory elements, not "\", but with a volume name separate from the path name with a ":", similar to Windows. But what makes matters more complicated, is that on AmigaOS "/" is equivalent to "." on Unix systems, and "//" equivalent to "..", and "."/".." are legal filenames. AmigaOS doesn't have an equivalent to "/" in Unix (everything is rooted in a volume, and there are many volumes), but ":" can be used to prefix a path to make it relative to the root of the current volume... It breaks all kinds of assumptions people make..
cwmma 10y ago
This list seems to imply relatively is only important orbiting black holes but the GPS satellites are far enough from earth or orbiting fast enough (both apply to satellites depending on orbit height) that relatively applies and the clocks have to be adjusted.
bmh100 10y ago
I appreciate the list of things to look out for, but what about solutions? That would increase the value of the article immensely.
ZoFreX 10y ago
I have two suggestions, one useful and one less useful: 1) Given two events that happened in two different locations, one happened before the other or they happened at the same time [1] 2) All the devices comprising your system will agree on what offset each timezone is (alternatively: will have the same version of the tzdb) Number 2 is not a theoretical problem: if you have users in a country where the timezone can change at short notice (e.g. Turkey), how do you handle the fact that across all the different Android versions their phones will have different opinions on what the time is and what timezone they are in? [1] https://en.wikipedia.org/wiki/Relativity_of_simultaneity https://en.wikipedia.org/wiki/Relativity_of_simultaneity
- GeneralMayhem 10y ago
  (1) is not a theoretical problem in distributed systems. I work on a system that involves malicious actors such that allowing subtle timing problems can cause very real revenue impact, and defining consistency in a way that converges quickly with only what amounts to a vector-clock definition of time is tons of fun.
  - ZoFreX 10y ago
    I was deliberately careful with the wording - yes, in distributed systems, we may be unable to determine which event came first. But one of them did happen first in reality, we just can't tell which. However, in some cases (see the Wikipedia link) it's not even true that one of them did happen first - it depends on where you observe them from and there is no definitive answer! Relativity is weird.
MatthewWilkes 10y ago
I had some fun ones a couple of years ago on this theme: * Every week has a weekend * Weekends are always Saturday and Sunday * Weekend days never change within a locale * Weekend days are always on consecutive days
- emddudley 10y ago
  Are you talking about historical dates and calendars, or maybe different cultural calendars? Could you provide some examples? In the US today I don't think these four falsehoods are ever false.
  - falcolas 10y ago
    I imagine the concept of weekends, as related to most computing, has to do with a work schedule. Back when I used to work the night shift on non-standard days, doing any kind of scheduling with an electronic device was a real pain. Even today many scheduling tools don't cope well with overnight meetings.
  - seren 10y ago
    Notably, Muslim countries often have a the Friday off, so sometimes the week-end is Friday/Saturday, in other countries it is Thursday/Friday. https://en.wikipedia.org/wiki/Workweek_and_weekend#Muslim_countries https://en.wikipedia.org/wiki/Workweek_and_weekend#Muslim_co... Another example from the same Wikipedia page : > Brunei Darussalam has a non-contiguous working week, consisting of Monday to Thursday plus Saturday. The days of rest are Friday and Sunday.
- wtbob 10y ago
  And then there's: * Weeks always start on Sunday vs. * Weeks always start on Monday
  - MatthewWilkes 10y ago
    Yep, that's the context we had. An EMEA app that had a 20 day calendar, had to handle different weekend dates, different start of week days and different text directionality.
tmaly 10y ago
I have had my fair share of dealing with these over the last decade. pulling data from processes that run in different timezones and trying to merge that all together has been really fun.
novaleaf 10y ago
if you think dealing with time is a problem, try measuring elapsed time on computers that sleep :) the solution i found (when dealing with this problem in C# a few years ago) is that you need to poll the time in an update loop (running at, say 10hz or whatever resolution you need). if you have a sudden jump in time between two loops, chances are the computer was asleep. or there was a leap second. or you are sampling local time instead of UTC and daylight savings just occurred, or the user crossed timezones. or the user changed their clock manually. Or the computer resynced with the time server (happens quite often, and can cause negative time to elapse. Better check the CPU for elapsed ticks instead!) man... this is starting to sound like roll-your-own-cryptography ;)
BurningFrog 10y ago
One thing I've had to explain to many programmers, at several different jobs: * A timestamp is not a date. Many people believe a timestamp is a "more detailed date". In reality, every timestamp is in (at least) two different dates, depending on what timezone you look at it in. The terrible java.util.Date is probably one reason.
imagist 10y ago
A case like this, which has a wide variety of exceptions that need to be updated as timezones change (yes, they do) is a perfect case for a library. The best I've ever found was JodaTime, but I no longer work in Java and no other language has an equivalent.
- huherto 10y ago
  Joda Time was "adopted" as a part of java 8 on the java.time.* packages.
  - imagist 10y ago
    Yeah, but that happened to late to help me. :/
splicer 10y ago
For iOS devs: mach time is just a more precise, monotonic equivalent to wallclock, and it never pauses :p See https://developer.apple.com/library/content/technotes/tn2169/_index.html https://developer.apple.com/library/content/technotes/tn2169...
btbuildem 10y ago
Let me just throw Easter in there, since nobody else has.. https://en.wikipedia.org/wiki/Computus https://en.wikipedia.org/wiki/Computus http://aa.usno.navy.mil/faq/docs/easter.php http://aa.usno.navy.mil/faq/docs/easter.php
sammorrowdrums 10y ago
Also: * Leap years occur every 4 years
- sammorrowdrums 10y ago
  * Timezones never change
huherto 10y ago
It looks like some of these should be taken care on the operations side. Sort of like https://12factor.net/ https://12factor.net/ As a programmer you need to be able to make assumptions, otherwise it gets crazy complicated.
tracker1 10y ago
One recently that bugs me to no end, is someone at the company I work for created an API that takes a date parameter in YYYY/DD/MM format... wtf?!? YYYY-MM-DD is fine, when year is first, the month should always be next... that's universal at this point. mm/dd vs dd/mm is a problem, but it's always ymd when year is first. sigh The issues with timezones, and offset calculations can be problematic too... fortunately most environments and language platforms have systems in place to at least convert to/from local to utc, while that doesn't resolve for time drift, or mis-set times, it does handle a lot of issues to always use utc, or use date/time + location if not using utc... Another hard one is leap minutes/seconds, daylight savings time changes, etc.
- nojvek 10y ago
  In US a lot of paper forms use yy-mm-dd. America has crazy units and standards.
  - tracker1 10y ago
    US is MM/DD/YYYY for most paper forms... whenever year is first, it's always year-month-day, period.
deathanatos 10y ago
I discovered this one, recently: > Excel stores dates as sequential serial numbers so that they can be used in calculations. By default, January 1, 1900 is serial number 1, and January 1, 2008 is serial number 39448 because it is 39,447 days after January 1, 1900. That's from the Microsoft's documentation of Excel[1]. Note this part: "because [Jan 1, 2008] is 39,447 days after January 1, 1900" In [3]: (datetime.datetime(2008, 1, 1) - datetime.datetime(1900, 1, 1)).days Out[3]: 39446 Off by one, Microsoft. And yes, Excel does the same thing — i.e., the docs match the product. If you're wondering why, it's b/c Excel incorrectly thinks that 1900 is a leap year. (Also, this is why a lot of Window's clocks track time since 1901, as it makes leap year calculations simpler… for now.) [1]: https://support.office.com/en-us/article/DATEVALUE-function-df8b07d4-7761-4a93-bc33-b7471bbff252 https://support.office.com/en-us/article/DATEVALUE-function-...
- ufmace 10y ago
  I recall reading somewhere on Joel on Software that I can't find at the moment that Microsoft did this deliberately to duplicate a bug in Lotus 1-2-3, because they needed perfect compatibility with formulas and dates with 1-2-3 to get people to switch over. And Lotus 1-2-3 reportedly had this bug because, at the time it was written, the code to account for that case correctly legitimately took up too much space and was dropped, with Lotus figuring that not too many people would notice. And of course, Microsoft can't change it now, or else they'll potentially break a ton of people's spreadsheets that already work around it.
Balgair 10y ago
I've got 2: -Your clock works the way you think it does I was working for a company that makes pico-second clocks. It turns out, that all clocks experience drift. Like a gyroscope, each clock has it's own peculiarities and hyper-local environment, and like a gyroscope, they all tend to record and count time in different ways. If you have a clock, you know what time it is. But if you have 2 clocks, you are never sure. Now, we extend this to many clocks and we then have an ensemble of them, and (thank god) it ends up being a normal distribution that we then take the mean of. Now with picosecond clocks, the local gravitational environment, temperature, wear history, etc all end up being very big factors in time keeping. For most systems, this would be a catastrophe. You'd have to bury the clocks in some mountain, gravitationally 'shielded' away from things, temperature controlled, super clean, etc, and only take the time once a day or something. It turns out that if you run those calculations, you can only keep time to a part in 10^-16. Fortunately though, we discipline time to that of the Earth. Days and years are the thing we must subside to. And these things are only good to about a part in 10^-12, so we have 10,000 parts of 'error' to live in. It turns out, the Earth is a pretty bad clock, overall. It was pretty cool, years after I left that job, to walk into NIST and see an ensemble of our old clocks in the room where the US second is measured. -Leap seconds always occur on the same date/time of the year. The terrible earth-quake in Fukushima really did a number on the international timing community too. The change in distribution of mass of the Earth was so much that it slowed the year down by ~1 millisecond in total. I hope that the readers of the article and the rest of the comments here can appreciate that such a change, though to a normal person is small, is actually quite a lot for computers and other logic based systems. The 'leap-second', in reality a millisecond, was chosen to occur not on the last night of February of the following year, but was pushed forward to the last night of June. This did not make the people that sell super precise clocks very happy. Typically, the leap-second night is one of mayhem for clock sellers and the people that support the sold clocks. As this usually happens at midnight, far past when you have to put your kids to bed, the 'push notification' of the new time is in weary hours. That means starting about 1 minute after midnight, you start getting flooded with calls from your customers. Now, the purchasers of hyper-precise clocks tend to be very wealthy and powerful and very angry and sleepy that all of their very expensive computers are now 'all broke'd' in the literal middle of the night. Most of the time, you can reach out to the IT guys of these large oil&gas, Wall-Street, military, educational, and other types of firms and make contacts and let them know things will start to get out of whack. And they tend to learn that this usually happens in early March. Well, for this end of June leap-second, we knew things were going to be hairy. And they were. I was not even close to senior enough to be on those calls, but I came in the next day and all the senior guys were STILL on the phones with the various companies. When I left, they were on the phones still. I think they must have been up for at least 50 hours, judging by the amounts of RipIts scattered about the floors. That is what I call a salary job. In all, I learned that humans think that time works in one way, but it really is 'what a clock measures' and is an abstract concept we put a lot of value into. And no, we will never be able to make a program that can take all of these considerations into account. All that will do is make the troubleshooting process a lot longer. Time is ephemeral, the Earth makes a bad clock, and mammals are diurnal. Those 3 things make clocks and time-keeping a 'hands on' job.
abc_lisper 10y ago
Much needed. Thanks. Handling time is difficult, and Java's api(older ones) didn't make life easy. I have fixed many subtle bugs in my code related to time, over the years.

183 points by kushti 10y ago

Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash. Make it loud and clear that something is wrong. Any attempts to rectify the problem, and most attempts to even detect it will only add surface area to the code, surface area where you can screw up and introduce bugs. Could the system's timezone change? Yes. If you're manipulating time sanely, you're already using a timezone aware time class - particularly when serializing - and that's great. But if you're uncertain, it's best not to try to rectify. Your program will never be able to guess with any success. Almost all of this post strikes me as along the vein of the questions of Babbage - "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" Almost all of these are the wrong numbers. Rather than leading you to the simple, correct solution (Use good serialization formats and timezone aware datastructures) it leads you down a path of paranoia, convinced the world is out to get you. If you're programming for that world, you're either a DRM programmer and should burn in hell, or you're doing it wrong. Trust your environment and OS and make damn sure that when you're setting up those layers you set them up right - Don't worry that every second open() call will return an invalid filehandle, just because.

Rapzid 10y ago
Yes. To further play devil's advocate; a lot of times it's better to just write time handling in a naive manner. Even if you know it will fail under certain circumstances, the program might not need to always be correct to be successful. I HATE writing stuff like this, but sometimes the ROI is just not there.
kingcong5 10y ago
Yeah, same thing I was thinking. Being exact in time can drive you crazy. Don't run yourself in the ground.
kasparsklavins 10y ago
There are situations in which it is not acceptable to make a "loud crash", e.g., while a plane is flying. There was a quote by a nasa engineer that an incorrect action is better than no action at all, but I cant find it at the moment.
- gpderetta 10y ago
  I'm pretty sure that if a flight computer detects an inconsistency, it will immediately reboot, and not try to limp along in a bad state. Either the reboot is fast enough to recover quickly enough, or the redundant systems will take over.
yoo1I 10y ago
No. Yesterday my friends Mac crashed hard while they were working on a foolishly unsaved one-and-a-half page document in LibreOffice. At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" . Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working. This "attempt to rectify" the problem, could only have made things better not worse, so that's reasonable to implement. I am not saying that every problem needs a solution like this. But blanket statements like "crash whenever there is a problem with your environment", while certainly the correct way to do it in some cases, leads to software that's really shitty use if that's all the software does. Because while > Almost all of these are the wrong numbers. is correct from a programmers point of view, we aren't talking about the numbers a user put in, but rather numbers that the user has no control about. And not many things are more annoying than computers doing unexpected things for reasons that are incomprehensible to you.
- elmigranto 10y ago
  I don't think parent comment meant ditching swap files in text editors or reboot on GPS errors in plane's autopilot. Just sort out upfront where the value is (user data, safety and reliability, rendering fast, etc…) and set requirements appropriately. There is no reason to handle leap seconds in a flappy bird game, or fork your database server to implement "proper" time handling with historically correct time zones and all the appropriate conversions between them, if you are writing a Twitter client.
- gpderetta 10y ago
  >At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" . > Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working. Uh, that's exactly what the OP was advocating, if I understand correctly. On a consistency check failure (i.e. an assert), crash immediately [1]. If the application correctly handle transactional state changes, it will be able to recover on startup from the replay log, as all changes are immediately persisted on the log. This approach is known as "Crash Only Software", and it is pretty much the only approach for writing robust applications. [1] Syncing the replay log to stable storage can be a good thing though.
fauigerzigerk 10y ago
>Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash. When it comes to time, a crash is not the most likely outcome of not thinking about what could happen. More likely your code will stall or do the wrong thing. Think about polling, pinging other systems or rate limiting. At the end of daylight savings time your code could easily stall for an hour or DDOS another system because rate limiting fails.

Animats 10y ago

Leap seconds are a big enough problem that stock markets shut down for them.[1] Google starts advancing their clocks hours in advance of a leap second. Power companies take about four hours to catch up after one. (Every 1800 RPM generator has to make 30 extra turns.) Very few systems properly handle a 61-second minute. Unix timestamps are fundamentally incompatible with leap seconds. [1] http://money.cnn.com/2015/06/29/technology/leap-second/ http://money.cnn.com/2015/06/29/technology/leap-second/

elmigranto 10y ago
Sure is a problem when you are writing a system for processing stocks, not really if you are making a calendar app or ecommerce website. I guess what I mean is that things like that are a nice piece of trivia, little fun facts, but nothing to be concerned of for most of us.
- aardvark179 10y ago
  Until you assume midnight one day plus 24 * 3600 seconds will equal midnight the next day. These kinds of problems will bite you in all sort of places you don't think you need to worry about them.
sparky_z 10y ago
"Every 1800 RPM generator has to make 30 extra turns." I'm having trouble wrapping my my head around this one. If the goal is maintaining a steady output, shouldn't they keep revolving at the same rate, without worrying about what day the "current" second (no pun intended) belongs to? After all, I'm assuming they don't "catch up" after leap days, they just run for an extra day at the same output level. Why would leap seconds be different? Put another way, what do they need to spread those extra 30 turns over a 4 hour catch up period? Weren't they given an extra second in which to take care of them?
- XorNot 10y ago
  The power grid doesn't work if disparate phases aren't synchronized. On a very large scale this is why HVDC is used, but on smaller scales its still more cost-effective to coordinate with GPS time since it's atomic-clock backed.

inlined 10y ago

My favorite time-related false beliefs are about time zones: 1. 1AM happens 24 times a day 2. Ok, so 1A is screwed up because of DST. Noon happens 24 times a day. 3. The maximum distance between time zones is 24 hrs 4. Time zones are in 1hr increments 5. In half hour increments? 6. UTC offset is a good thing to store in someone's profile 7. People live in a fixed number of UTC offsets

jaggederest 10y ago
Add to it: Time zones change linearly from east to west and west to east For each physical location there is exactly one time zone
- inimino 10y ago
  And: The time zone you use is a matter of geography, not political affiliation.
  - TeMPOraL 10y ago
    Understanding that point suddenly makes half of the list much more obvious.
- plopilop 10y ago
  You can also add: * One geographical location won't change its timezone over time * Apart from DST, one geographical location won't change its timezone over time * If a location changes timezone, the leap is always less than an hour, maybe a few hours * Ok, less than a day * Why are you talking about 2011, December 30th in Samoa Islands?
- 77pt77 10y ago
  > For each physical location there is exactly one time zone Care to elaborate?
  - Crespyl 10y ago
    I don't know of any parcels of land that are simultaneously in more than one zone, but I do know that (until recently?) Indiana used to change time zones from Eastern to Central instead of using DST.

calanya 10y ago

That the clock always moves forward. As one example, some clocks are cpu specific (rather than system specific). When a thread gets scheduled to a different cpu, it might be talking to a different clock, and getting a backwards time. The user might also be changing the clock while the program is running, of course. If the forward direction of time is important, make sure the the source of time is a monotonic clock API.

saretired 10y ago
All I can add is a warning about running NTP if you are maintaining a priority queue of time-stamped actions (now + delta, where delta depends on the action): use CLOCK_MONOTONIC instead of wall time.

po1nter 10y ago

This is a very interesting video by Computerphile on this subject: https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY

mofle 10y ago

More interesting falsehoods in this awesome list: https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood

dredmorbius 10y ago
Nice. Includes the one I'd just posted as well. I recommend submitting that to HN. Looks as if it was a couple of months ago, but definitely worth the resubmission as it didn't take: https://hn.algolia.com/?query=https:%2F%2Fgithub.com%2Fkdeldycke%2Fawesome-falsehood&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=https:%2F%2Fgithub.com%2Fkdeld...

rdtsc 10y ago

I got two I noticed over the years: * Didn't think about time at all. In most cases most don't think about time until it becomes a problem. It often ends up with a system which behaves in surprising ways, and is the equivalent to the developer believing any of those things in the article. But there is a difference in them believing those falsehoods, and simply not being a aware of them at all. * Time moves forward This is probably the biggest gotcha of all. Just imagine how many times int the past you did dt = now() - t0, then did something with dt like sleep(dt). Well time will move backwards sometimes and dt is negative. I bet this will make most people here worried and they'll think about code they wrote like that (sure did). I have seen systems freeze for example because they end up sleeping for a huge amount of time (negative number was cast to an unsigned huge number). A small advice on how to improve errors related to time is to abstract it away from algorithms and code as much as possible. Instead of always calling gettimeofday() / time() / now() function to get the current time, in a piece of lower level code, try to pass it in as an argument. That will make code testable. I have seen fun failing test cases. Something like encoding the current time the test was written and a dt to current time. The test was working for years then started failing eventually because of the hard coded time.

baq 10y ago
> * Time moves forward I agree. Smart library developers seem to agree, too. Example from Python docs: https://docs.python.org/3/library/time.html#time.monotonic https://docs.python.org/3/library/time.html#time.monotonic The only (cough) problem is drilling this knowledge into developers' heads - and as you said, awareness that there even is a problem!
Iv 10y ago
> (negative number was cast to an unsigned huge number) Slightly off-topic pet-peeve of mine: never used unsigned, unless you have an extremely good reason for it. Saving one bit is not one of them. You never know when you will need to do arithmetic on your unsigned values. Time going backwards is a good example of this.
- __s 10y ago
  This crops up in Rust's std::time::Duration which has no concept of negative duration

okket 10y ago

Previous discussion: https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208 (4 years ago, 213 comments)

amelius 10y ago

Falsehood non-physicists believe about time: simultaneity. https://www.youtube.com/watch?v=wteiuxyqtoM https://www.youtube.com/watch?v=wteiuxyqtoM

MarkMc 10y ago

My experience is that for most applications, programmers really only need to understand 3 types: 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. 2. A date in the Gregorian calendar. This could also be an integer offset from a particular day, but it's better to encapsulate it in a class that allows you to add days or months, get the number of days between two dates, etc. 3. A timezone which is necessary to convert between the two types mentioned above. Java has default classes to represent Types 1 and 3, but is missing a simple class for Type 2. So I designed one myself: http://calendardate.sourceforge.net http://calendardate.sourceforge.net

zAy0LfpBZLC8mAC 10y ago
> 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. That's already an undefined statement ;-) I mean, I guess you are actually aware of it, but that's not actually an instant in time, that's about 24 different spans of time, each 86400000 milliseconds long.
- inimino 10y ago
  It took me a while to figure out what you are pointing out. GP left out the time and timezone, but we still recognize that date as shorthand referring to the Unix epoch.
- MarkMc 10y ago
  Whoops sorry I should have said January 1,1970 GMT!
dlubarov 10y ago
Did you see Java 8's java.time classes? There's LocalDateTime for type 2, and Instant which is like a much improved Date. Both obviously Joda inspired.
- MarkMc 10y ago
  Thanks - I didn't know Java 8 had incorporated Joda time. Actually LocalDate is a better representation for Type 2 because it doesn't encapsulate minutes, hours or seconds. This would make it ideal to represent "John's birthday" or "date on which the customer repaid loan". In fact, I'm disappointed that Java has incorporated Joda time - new Java programmers will now need to crawl over a huge pile of time-based classes to pick out the ones they need, when for 99% of cases only the same 3 types are necessary. How many of these novice users will incorrectly use LocalDateTime to represent Type 1?

partycoder 10y ago

Dates and times, floating point numbers, even strings... there will be always magic in how data is represented/encoded. Now in the case of dates, there's the epoch, and a precision determined in terms of that epoch, there are compatibility workarounds between 32-bit and 64-bit time... we add have leap days and leap seconds, and of course: the fact that clocks go out of sync, timezones and daylight saving time, as well as a long long list of things. Some countries move dates for DST every year. Then, there are days that "do not exist" (September 1752 in UK/US, etc, when they moved from the julian to the gregorian calendar).

Arnt 10y ago

Time education in practice: The linux kernel boots 5 minutes before the end of time, so that anyone whose code would break when jiffies wraparound will see that breakage soon after boot. That's a great, great feature.

fbender 10y ago
Care to elaborate on that?
- Arnt 10y ago
  The linux kernel's basic time unit is the jiffy, which wraps around every ~497 days and is visible to userspace using clock_gettime(CLOCK_MONOTONIC). In order to make sure that bugs don't occur only after 497 days, the jiffy value doesn't start at 0. Rather, the boot-time value is such that the jiffy value will wrap around after five minutes. One of my brothers worked for an embedded device manufacturer that got bitten. The software worked great unless it was started in the first five minutes after a reboot. But since booting and waiting five minutes is easy, the fix was, too. The nonzero boot-time value made it simple to fix a bug that occurs every 497 days. Fantastic, say I.
  - Klathmon 10y ago
    What a great solution! It's a "hostile" move that probably ends up preventing countless bugs in high-uptime systems.
  - carterehsmith 10y ago
    Ha, looks like they did not fix the bug? That is, they did not account for wraparound, they just avoided it. Is that correct?
    - Arnt 10y ago
      Where my brother worked, you mean? They ensured that their software measured speed correctly in the hosts's fifth minute of uptime, and in all other minutes too.

saittam 10y ago

And because time is so simple, we figured to just rely on accurate time for TLS certificate validation and thus the security of HTTPS. </sarcasm>

dredmorbius 10y ago

We could just cut to the chase: Falsehoods programmers believe: https://encrypted.google.com/search?hl=en&q=%22things%20programmers%20believe%20about%22#hl=en&q=falsehoods+programmers+believe+about+names&search_plus_one=form https://encrypted.google.com/search?hl=en&q=%22things%20prog... http://www.metafilter.com/117073/Falsehoods-Programmers-Believe http://www.metafilter.com/117073/Falsehoods-Programmers-Beli... By way of lists, a pretty comprehensive one: http://spaceninja.com/2015/12/08/falsehoods-programmers-believe/ http://spaceninja.com/2015/12/08/falsehoods-programmers-beli... More in another comment: https://news.ycombinator.com/item?id=12675830 https://news.ycombinator.com/item?id=12675830

rurban 10y ago
I miss falsehoods about pathnames: * That there's never a \0 in a pathname wchar names on MSWin UNICODE and WinCE. Symbian uses UTF16. * That paths are seperated by / Yes, Windows NT accepts /, VMS, VOS, RISC OS also, but MacOS classic had :, and VMS uses []. And there are still \ pathseps only, like DOS, OS/2, SYMBIAN, Novell NETWARE, AmigaOS4. Native Acorn RISC OS uses . as pathsep and : as in DOS. Just the easiest ones.
- Bouncingsoul1 10y ago
  "* That paths are seperated by /" The day I learnded that Korean Windows version uses a Won sign and Japanes use a Yen sign was very bad day.
- vidarh 10y ago
  AmigaOS paths are separated with "/" between directory elements, not "\", but with a volume name separate from the path name with a ":", similar to Windows. But what makes matters more complicated, is that on AmigaOS "/" is equivalent to "." on Unix systems, and "//" equivalent to "..", and "."/".." are legal filenames. AmigaOS doesn't have an equivalent to "/" in Unix (everything is rooted in a volume, and there are many volumes), but ":" can be used to prefix a path to make it relative to the root of the current volume... It breaks all kinds of assumptions people make..

cwmma 10y ago

This list seems to imply relatively is only important orbiting black holes but the GPS satellites are far enough from earth or orbiting fast enough (both apply to satellites depending on orbit height) that relatively applies and the clocks have to be adjusted.

bmh100 10y ago

I appreciate the list of things to look out for, but what about solutions? That would increase the value of the article immensely.

ZoFreX 10y ago

I have two suggestions, one useful and one less useful: 1) Given two events that happened in two different locations, one happened before the other or they happened at the same time [1] 2) All the devices comprising your system will agree on what offset each timezone is (alternatively: will have the same version of the tzdb) Number 2 is not a theoretical problem: if you have users in a country where the timezone can change at short notice (e.g. Turkey), how do you handle the fact that across all the different Android versions their phones will have different opinions on what the time is and what timezone they are in? [1] https://en.wikipedia.org/wiki/Relativity_of_simultaneity https://en.wikipedia.org/wiki/Relativity_of_simultaneity

GeneralMayhem 10y ago
(1) is not a theoretical problem in distributed systems. I work on a system that involves malicious actors such that allowing subtle timing problems can cause very real revenue impact, and defining consistency in a way that converges quickly with only what amounts to a vector-clock definition of time is tons of fun.
- ZoFreX 10y ago
  I was deliberately careful with the wording - yes, in distributed systems, we may be unable to determine which event came first. But one of them did happen first in reality, we just can't tell which. However, in some cases (see the Wikipedia link) it's not even true that one of them did happen first - it depends on where you observe them from and there is no definitive answer! Relativity is weird.

MatthewWilkes 10y ago

I had some fun ones a couple of years ago on this theme: * Every week has a weekend * Weekends are always Saturday and Sunday * Weekend days never change within a locale * Weekend days are always on consecutive days

emddudley 10y ago
Are you talking about historical dates and calendars, or maybe different cultural calendars? Could you provide some examples? In the US today I don't think these four falsehoods are ever false.
- falcolas 10y ago
  I imagine the concept of weekends, as related to most computing, has to do with a work schedule. Back when I used to work the night shift on non-standard days, doing any kind of scheduling with an electronic device was a real pain. Even today many scheduling tools don't cope well with overnight meetings.
- seren 10y ago
  Notably, Muslim countries often have a the Friday off, so sometimes the week-end is Friday/Saturday, in other countries it is Thursday/Friday. https://en.wikipedia.org/wiki/Workweek_and_weekend#Muslim_countries https://en.wikipedia.org/wiki/Workweek_and_weekend#Muslim_co... Another example from the same Wikipedia page : > Brunei Darussalam has a non-contiguous working week, consisting of Monday to Thursday plus Saturday. The days of rest are Friday and Sunday.
wtbob 10y ago
And then there's: * Weeks always start on Sunday vs. * Weeks always start on Monday
- MatthewWilkes 10y ago
  Yep, that's the context we had. An EMEA app that had a 20 day calendar, had to handle different weekend dates, different start of week days and different text directionality.

tmaly 10y ago

I have had my fair share of dealing with these over the last decade. pulling data from processes that run in different timezones and trying to merge that all together has been really fun.

novaleaf 10y ago

if you think dealing with time is a problem, try measuring elapsed time on computers that sleep :) the solution i found (when dealing with this problem in C# a few years ago) is that you need to poll the time in an update loop (running at, say 10hz or whatever resolution you need). if you have a sudden jump in time between two loops, chances are the computer was asleep. or there was a leap second. or you are sampling local time instead of UTC and daylight savings just occurred, or the user crossed timezones. or the user changed their clock manually. Or the computer resynced with the time server (happens quite often, and can cause negative time to elapse. Better check the CPU for elapsed ticks instead!) man... this is starting to sound like roll-your-own-cryptography ;)

BurningFrog 10y ago

One thing I've had to explain to many programmers, at several different jobs: * A timestamp is not a date. Many people believe a timestamp is a "more detailed date". In reality, every timestamp is in (at least) two different dates, depending on what timezone you look at it in. The terrible java.util.Date is probably one reason.

imagist 10y ago

A case like this, which has a wide variety of exceptions that need to be updated as timezones change (yes, they do) is a perfect case for a library. The best I've ever found was JodaTime, but I no longer work in Java and no other language has an equivalent.

huherto 10y ago
Joda Time was "adopted" as a part of java 8 on the java.time.* packages.
- imagist 10y ago
  Yeah, but that happened to late to help me. :/

splicer 10y ago

For iOS devs: mach time is just a more precise, monotonic equivalent to wallclock, and it never pauses :p See https://developer.apple.com/library/content/technotes/tn2169/_index.html https://developer.apple.com/library/content/technotes/tn2169...

btbuildem 10y ago

Let me just throw Easter in there, since nobody else has.. https://en.wikipedia.org/wiki/Computus https://en.wikipedia.org/wiki/Computus http://aa.usno.navy.mil/faq/docs/easter.php http://aa.usno.navy.mil/faq/docs/easter.php

sammorrowdrums 10y ago

Also: * Leap years occur every 4 years

sammorrowdrums 10y ago
* Timezones never change

huherto 10y ago

It looks like some of these should be taken care on the operations side. Sort of like https://12factor.net/ https://12factor.net/ As a programmer you need to be able to make assumptions, otherwise it gets crazy complicated.

tracker1 10y ago

One recently that bugs me to no end, is someone at the company I work for created an API that takes a date parameter in YYYY/DD/MM format... wtf?!? YYYY-MM-DD is fine, when year is first, the month should always be next... that's universal at this point. mm/dd vs dd/mm is a problem, but it's always ymd when year is first. sigh The issues with timezones, and offset calculations can be problematic too... fortunately most environments and language platforms have systems in place to at least convert to/from local to utc, while that doesn't resolve for time drift, or mis-set times, it does handle a lot of issues to always use utc, or use date/time + location if not using utc... Another hard one is leap minutes/seconds, daylight savings time changes, etc.

nojvek 10y ago
In US a lot of paper forms use yy-mm-dd. America has crazy units and standards.
- tracker1 10y ago
  US is MM/DD/YYYY for most paper forms... whenever year is first, it's always year-month-day, period.

deathanatos 10y ago

I discovered this one, recently: > Excel stores dates as sequential serial numbers so that they can be used in calculations. By default, January 1, 1900 is serial number 1, and January 1, 2008 is serial number 39448 because it is 39,447 days after January 1, 1900. That's from the Microsoft's documentation of Excel[1]. Note this part: "because [Jan 1, 2008] is 39,447 days after January 1, 1900" In [3]: (datetime.datetime(2008, 1, 1) - datetime.datetime(1900, 1, 1)).days Out[3]: 39446 Off by one, Microsoft. And yes, Excel does the same thing — i.e., the docs match the product. If you're wondering why, it's b/c Excel incorrectly thinks that 1900 is a leap year. (Also, this is why a lot of Window's clocks track time since 1901, as it makes leap year calculations simpler… for now.) [1]: https://support.office.com/en-us/article/DATEVALUE-function-df8b07d4-7761-4a93-bc33-b7471bbff252 https://support.office.com/en-us/article/DATEVALUE-function-...

ufmace 10y ago
I recall reading somewhere on Joel on Software that I can't find at the moment that Microsoft did this deliberately to duplicate a bug in Lotus 1-2-3, because they needed perfect compatibility with formulas and dates with 1-2-3 to get people to switch over. And Lotus 1-2-3 reportedly had this bug because, at the time it was written, the code to account for that case correctly legitimately took up too much space and was dropped, with Lotus figuring that not too many people would notice. And of course, Microsoft can't change it now, or else they'll potentially break a ton of people's spreadsheets that already work around it.

Balgair 10y ago

I've got 2: -Your clock works the way you think it does I was working for a company that makes pico-second clocks. It turns out, that all clocks experience drift. Like a gyroscope, each clock has it's own peculiarities and hyper-local environment, and like a gyroscope, they all tend to record and count time in different ways. If you have a clock, you know what time it is. But if you have 2 clocks, you are never sure. Now, we extend this to many clocks and we then have an ensemble of them, and (thank god) it ends up being a normal distribution that we then take the mean of. Now with picosecond clocks, the local gravitational environment, temperature, wear history, etc all end up being very big factors in time keeping. For most systems, this would be a catastrophe. You'd have to bury the clocks in some mountain, gravitationally 'shielded' away from things, temperature controlled, super clean, etc, and only take the time once a day or something. It turns out that if you run those calculations, you can only keep time to a part in 10^-16. Fortunately though, we discipline time to that of the Earth. Days and years are the thing we must subside to. And these things are only good to about a part in 10^-12, so we have 10,000 parts of 'error' to live in. It turns out, the Earth is a pretty bad clock, overall. It was pretty cool, years after I left that job, to walk into NIST and see an ensemble of our old clocks in the room where the US second is measured. -Leap seconds always occur on the same date/time of the year. The terrible earth-quake in Fukushima really did a number on the international timing community too. The change in distribution of mass of the Earth was so much that it slowed the year down by ~1 millisecond in total. I hope that the readers of the article and the rest of the comments here can appreciate that such a change, though to a normal person is small, is actually quite a lot for computers and other logic based systems. The 'leap-second', in reality a millisecond, was chosen to occur not on the last night of February of the following year, but was pushed forward to the last night of June. This did not make the people that sell super precise clocks very happy. Typically, the leap-second night is one of mayhem for clock sellers and the people that support the sold clocks. As this usually happens at midnight, far past when you have to put your kids to bed, the 'push notification' of the new time is in weary hours. That means starting about 1 minute after midnight, you start getting flooded with calls from your customers. Now, the purchasers of hyper-precise clocks tend to be very wealthy and powerful and very angry and sleepy that all of their very expensive computers are now 'all broke'd' in the literal middle of the night. Most of the time, you can reach out to the IT guys of these large oil&gas, Wall-Street, military, educational, and other types of firms and make contacts and let them know things will start to get out of whack. And they tend to learn that this usually happens in early March. Well, for this end of June leap-second, we knew things were going to be hairy. And they were. I was not even close to senior enough to be on those calls, but I came in the next day and all the senior guys were STILL on the phones with the various companies. When I left, they were on the phones still. I think they must have been up for at least 50 hours, judging by the amounts of RipIts scattered about the floors. That is what I call a salary job. In all, I learned that humans think that time works in one way, but it really is 'what a clock measures' and is an abstract concept we put a lot of value into. And no, we will never be able to make a program that can take all of these considerations into account. All that will do is make the troubleshooting process a lot longer. Time is ephemeral, the Earth makes a bad clock, and mammals are diurnal. Those 3 things make clocks and time-keeping a 'hands on' job.

abc_lisper 10y ago

Much needed. Thanks. Handling time is difficult, and Java's api(older ones) didn't make life easy. I have fixed many subtle bugs in my code related to time, over the years.