4 ms·

> 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 mi

> 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 is if your database uses a datetime format that's equally human readable and unambiguous, MySQL users might use YYYY-MM-DD hh:mm:ss or YYYY-MM-DD hh:mm:ss.sss with an assumed and well documented UTC timezone.)

boopdewoop 2y ago
Why not just use epoch? render it however you like. - Posted at 1724222105
- lionkor 2y ago
  I prefer human readable datetime for debugging, because there are a lot of programs which have timings and timeouts for certain operations. Being able to quickly observe that a timeout happened in 500 ms instead of 1.5s would be interesting, epoch does not show you this information. Similar with quickly jumping to a certain day.
  - Dylan16807 2y ago
    > Being able to quickly observe that a timeout happened in 500 ms instead of 1.5s would be interesting, epoch does not show you this information. 1724222105000 and 1724222105.000000 are common forms that solve that problem.
mjevans 2y ago
https://ijmacd.github.io/rfc3339-iso8601/ https://ijmacd.github.io/rfc3339-iso8601/ 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.

boopdewoop 2y ago

Why not just use epoch? render it however you like. - Posted at 1724222105

lionkor 2y ago
I prefer human readable datetime for debugging, because there are a lot of programs which have timings and timeouts for certain operations. Being able to quickly observe that a timeout happened in 500 ms instead of 1.5s would be interesting, epoch does not show you this information. Similar with quickly jumping to a certain day.
- Dylan16807 2y ago
  > Being able to quickly observe that a timeout happened in 500 ms instead of 1.5s would be interesting, epoch does not show you this information. 1724222105000 and 1724222105.000000 are common forms that solve that problem.

mjevans 2y ago

https://ijmacd.github.io/rfc3339-iso8601/ https://ijmacd.github.io/rfc3339-iso8601/ 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.