Falsehoods Programmers Believe About Time (2012)
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.