Can we talk about all the problems with dates formated as "today", "tomorrow" or "2 hours ago" when trying to figure out how far apport two log-events happened? I at least want an OPTION to set that I want all dates down to the second exactly when they happened... And in a standard format with Y-M-D H:m:s that can sort naturally. The most significant part first, the least significant last.
> in a standard format with Y-M-D H:m:s Make sure that has a timezone (or better still, is explicitly in UTC). Also, bytes are cheap these days, let's have millisecond precision seconds there too. Lets go full ISO 8601 and use yyyy-mm-ddThh:mm:ss.sssZ at least this way you have a recognised standard to appeal to if some other code or library can't parse your datetimes. (One reason I'd accept _not_ using ISO8601 dates…
RFC3339 allows (space) to replace the T, which is about 1000 times more readable for a human.
ISO8601 and RFC3339 both agree the time part of should include E.G. a Z for the Zulu (UTC) timezone abbreviation.
I'm of the mindset that unspecified timezones (the MySQL format mentioned YYYY-MM-DD hh;mm:ss etc) are 'undefined behavior' and therefore context dependent. For user facing applications they should be the local 'normal persons' timezone, while for operator (E.G. SQL console) and programmed interface facing tasks should be either UTC of TAI time, as expected by the system.