> Use ISO8601 date and time with offset info, always.
I think that's just sufficient for all use cases everywhere. I've been a software engineer for almost 25 years and, of all the universal truths I've encountered, implicit and unintended changes to datetime offset are the ones I've seen at every single job.
> I think [ISO8601 date and time with offset info is] sufficient for all use cases everywhere.
TLDR: Also, which timezone is used (not quite the same as offset) really does matter--UTC is great but you can't use it everywhere.
________
One of my favorite simple examples of this "here be dragons" for the new developer: Any system that schedules a future calendar-event.
Such events are typically pegged, implicitly if not explicitly, to a particular timezone or geographic context. For example: "The company's Virtual Summit will occur on November 2nd at 1PM Elbonian Xtremesunshine Time, hosted out of our central Elbonian headquarters."
In that scenario, it is impossible to know for sure how many seconds-from-now it will happen until the moment actually happens! "2023-11-02 13:00:00 EXT" is actually a contract or spec for recognizing a future condition, one that will shift if/when the relevant nation/province/city simply declares their clocks shall be set differently.
So if the Elbonian government alters their daylight-savings switchover to occur earlier on 11-01 instead of 11-06, then the summit just moved. Even if you scheduled everything UTC all along... Well, now the summit is overlapping lunchtime for everyone in Elbonia, so it moved from their perspective.
Absolutely, e.. an offset of +2:00 in e.g. 2023‐06‐28T18:00+02:00 could mean Berlin in the summer (Central European Summer Time, clocks will change) or in Johannesburg (South African Standard Time, not summer and clocks don't change). Same offset, different time zone, different clock change rules.
As you note, for some uses this _does_ make a difference and tracking which one you have can in these cases be important.
Ha, good one! One can only hope the Elbonian Parliament will have the sense to abolish this stupid Xtremesunshine time and observe one time zone year-round.
As I put in another comment, your class library might have a type that is equivalent to ISO 8601 data, indeed is convertible to and from it, but is a binary representation at runtime compatible with other types in the language.
So this technically isn't ISO8601, and certainly isn't "ISO8601 in a string", which is an _interchange format_ between application with potentially very different runtimes. I don't really recommend treating ISO8601 dates as mere strings, unless you intend to pass them through without even looking at the contents.
When you’re using JSON to pass around datetime data, Use ISO8601 date and time with offset info, always.
e.g. "transactionDate": "2023‐06‐28T15:55:22.511Z"