In almost any kind of business software, dates and times are vital pieces of information that need to be handled with care and precision. At first glance, these types of data may seem trivial to work with - almost as "easy" as working with numbers. But just like humble numbers occasionally show their thorns (e.g. in the form of rounding errors), dates and times can also be unwieldy.
Yes, you can conveniently store date and time information in memory or in a database. You can compare one date to another, sort items by time, even perform "arithmetic" operations with date/time objects. Indeed, most modern programming languages provide primitives and tools for easy handling of dates and times. The `datetime` module in the Python standard library is an excellent example and generally a joy to work with.
Unfortunately, this ease and simplicity can be misleading. It doesn't take much exposure to business processes and requirements to realise that dates and times can be trickier than they seem.
In fact, the relationship involving computerised time keeping systems and their interpretation by humans can be surprisingly error-prone. One obvious example that gives birth to such difficulties is the existence of different time zones around the world, and the necessity to manage data across these zones. Another is the various formats that humans use to represent dates and times, usually different across countries and cultures, sometimes even inconsistently so.
Thus, it becomes necessary to exercise caution when we handle dates and times programatically, especially in the context of business or financial software.
Experts have been well aware of these problems since before the dawn of digital computing and have devised different ways to make the situation more manageable. In more recent history (in 1988), the International Organization for Standardization (ISO) published the ISO-8601 standard ("Data elements and interchange formats – Information interchange – Representation of dates and times"), in an attempt to standardise the way, in which dates and times are represented across all geographies and industries that use the Gregorian calendar for date keeping and a 24-hour timekeeping system. While this standard representation is now widely accepted and implemented, there are still plenty of exceptions, both in terms of deviations from the standard and implementation-specific details.
A date-time object stored on a computer system is intended to symbolise a particular instance in time, with the necessary degree of precision. In Python, a plain `datetime.datetime` object usually does not contain information about the timezone. We call these "naive" datetime objects (as opposed to "timezone-aware" datetime objects), probably because we tend to naively believe that they are good enough most of the time. After all, when you look at your calendar or your clock, you're not used to seeing any timezone information there. In a business context, if you are mostly operating in one geographic area within a single timezone, you may never even think that you would need to worry about time-zones, so why complicate things, right?
Can you think of some examples of when and why this can be problematic?
What other kinds of problems have you encountered that can be traced back to dates and times being handled too naively? (Do you remember Y2K?)