Timezone handling
By far, the most common mistakes with temporal data that I come across stem from a misunderstanding of timezones. On the East Coast of the US where I live, I’ve witnessed many users try to read what they think is a date of 2024-01-01 out of a database, yet ironically end up with a date of 2023-12-31 in their analysis. While that is only offset by a day, the effects of that misalignment can greatly skew summaries that group dates into weekly, monthly, quarterly, or yearly buckets.
For those that have been bitten by an issue like that before, you may have already come to realize that the source system you were communicating with probably did give you a timestamp of 2024-01-01 00:00:00, presumed to be at midnight UTC. Somewhere along the line, an analyst on the East Coast of the US where I live may have had that translated into their local time, which is either four hours offset from UTC during daylight saving time, or five hours offset during standard time...
