Rules for working with dates and times
Published: |
Updated:
| by Julian Knight Reading time ~1 min.
📖 Posts
| 📎
Information Management, Data, Development, Software
| 🔖
Databases, Dates, DBA, Debugging, Development, Software, Solutions Architecture, Standards, Timestamps
Dates and times are incredibly complex. They can be different in different countries, languages. They are often inconsistent and have weird edge-cases. These are some basic rules I apply when working with dates and times.
when handling dates and timestamps, here are the foundation rules that I work to:
Always use ISO date format where possible (YYYY-MM-DD)
So that there can be no ambiguity and so that date strings will naturally sort
Always work in UTC (Aka Zulu time or GMT) except when displaying to the user
To avoid weird errors, especially with timezone and daylight savings transitions. It also makes date/time calculations a LOT easier.
When needing a string format for timestamps, always use ISO format
e.g.
2020-03-07T15:27:46.123ZThese are always unambiguous and easily machine parsed.
When specifying decimal seconds in a timestamp, avoid more than 3 decimal places
The parsing tool used in node-red-contrib-moment to parse input dates in different formats cannot cope with more than 3dp and may return strange dates, a problem that I reported in May 2019 but hasn’t been resolved.
It should also be noted that I’m not sure that MomentJS can cope with more than 9dp.
Also worth noting that JavaScript’s
Datenative object only supports up to 3dp anyway and will turn anything beyond that into zero’s.
References 🔗︎
parseFormat function issue for >3dp seconds resolution
The worst thing about this issue is that it can result in an incorrect date being returned but does not give a warning.
