ISO-8601

I agree with Randall .

When writing out dates as strings, please use the ISO-8601 format. It has a sensible collation order, and there’s no ambiguity about which field is where. (I lived through the Y2K nightmare, and we still have a decade to go before 2031 is behind us.)

https://xkcd.com/1179

Filenames are a particularly good place to use this format, as sort order tends to matter.

And no, I don’t especially care if your Y-M-D h:m:s timestamp has a spec-compliant capital “T” in the middle, or some friendlier character like ” ” SPACE or “-” dash.

zone offset

Additionally, notice that a stamp like this is only meaningful if we have extra context:

2021-12-18 23:59

There’s at least twenty-four instants in time that corresponds to.

Consider tacking on the needed context with every timestamp, using one of two approaches:

2021-12-18 23:59Z
2021-12-18 23:59+0000

Here is a very different instant in time: 2021-12-18 23:59+0800 .

Avoid suffixes like “PST”, as we can often find multiple time zones throughout the world which use same three letters for different offset.

binary timestamp

When using typed storage of timestamps, in memory, HDF5 binary file, postgres timestamp column, or similar, always use UTC, a zone offset of zero.

Almost always the right answer for storing a stamp is: number of seconds since the epoch. Typically that is midnight in Greenwich, 1970-01-01.

internal representation

There are many good things to say about python’s datetime module, including its support for timedeltas. But it has the somewhat regrettable concept of naïve vs. aware timestamps. Ignoring “aware” objects is certainly one feasible approach.

My advice? Explicitly init each timestamp as aware, with a UTC zone offset. Then the Right Thing is sure to happen, it’s nearly impossible to accidentally mix the two types of stamps.

prev next