Time is one of the trickiest things to handle in computer systems with historical data. As evidence of this, 2 of the 5 Simple IoT ADRs deal with time, and another ADR about time is in process.
According to timeanddate, the time changes at 2AM in the US. Grafana shows this on March 12, 2023:
If we are totalizing daily flow, what should we do on days when we add or subtract an hour? It probably does not matter in most cases, but in some, it may.
How do we handle this when time is used in rule schedules? Do we store time as UTC or local time + time zone?
When someone in a different time zone is looking at data, do we display the data’s local time or the user’s local time?
The simplest is to do everything in UTC, but this is a poor user experience when users have to translate every timestamp they process. Additionally, if time is used in schedule rules, then they need to be adjusted every time the time changes.
My opinion is that all systems and data storage (databases, logs, etc) always use only UTC. Then when presenting the data to humans in fancy ways like in GUIs or web interfaces, it’s the job of the GUI or web interface to translate the UTC timestamps into what ever localtime the human wants. For situations like daylight saving time changes, the GUI or web interface need to clearly show why a time happens twice or not at all on a given day with some kind of marker.
I do have a personal problem with the name “Universal Coordinated Time” as it’s not “universal” but it’s only global. Time on the moon or Mars being referenced to how fast the Earth is spinning seems like a silly way to keep time in those locations. 1 second should stay 1 second regardless of where you are, but even that isn’t true as it depends on how fast you’re traveling. Time is a funny thing
This prompted me to read up on UTC a bit, and I discovered it stands for “Coordinated Universal Time,” not “Universal Coordinated Time.” That is perhaps a little better, but it still seems “Global” would have been better than “Universal.”
