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.123Z

These 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 Date native object only supports up to 3dp anyway and will turn anything beyond that into zero’s.

References 🔗︎

The worst thing about this issue is that it can result in an incorrect date being returned but does not give a warning.


comments powered by Disqus