My favorite datetime format is "YYYY-MM-DD hh:mm:ss".
I consider it the "Markdown for time". It is human-friendly and computer-friendly at the same time. It is supported by many languages and databases. It is so elegant and common that even though it is not part of a standard, LLMs started to use it when writing answers:
I don't think I realized how many alternative formats there are for both 3339 and 8601. Most of those alternative formats are redundant. I like that this chart shows the venn diagram of where these standards intersect.
%F Equivalent to %Y-%m-%d (the ISO 8601 date format). (C99)
%T The time in 24-hour notation (%H:%M:%S). (SU)
The Op linked page did not recognise these. I tried with the "%FT%T%z" which works fine with date and strftime().
I've probably used %F and %T about 20 years with no issues linux, bsd and mac that I wrote code over the years.
BTW, It would be nice to see some reference or comparison how systems stdlib implementations match with these standards if there is one.
One gripe I've got with RFC3999 and it's not nice to have the semicolon in filename if you intend to use it file or directory name. As it conflicts and easily becoome issue when not quoted while using rsync or any command that thinks colon (:) separates and indicates host name. I'm not sure if colon would cause issues with windows but there is chance it could as it's used indicating device name.
ps. I had to implement many stdlib time.h defined functions my own between -89 - 92 for my then work as Turbo C 2.0 and 3.0/3.1 did not implement these. I recall that last time I touched these and fixed issues was when I got P.J. Plaugers The Standard C Library book when it was brand new -92. When earlier proprietary C-compliers libraries sources had not been available, that Plaugers book was was great help for many :)
Every programmer starts off thinking that dates and times are easy. “Just do …,” they’ll say. And then you realize that ISO 8601 has more than a few ways just to write down the time, let alone manipulate it. Dates and times are a very, very deep rabbit hole. Fortunately most of the time you can get by with just local dates and times or zoned dates and times.
fun fact - ATProto requires you to store all the datetime strings in a format that's compliant with both RFC 3339 and ISO 8601 plus you cannot specify time without date.
when I worked on datetime portion of Katproto, I had this link pinned for quite some time as a reference! ah, nostalgia...
also, post factum, I find this technical decision actually good - instead of supporting all possible variations of ISO 8601 or all the variations of RFC 3339, why not just support the intersection? that way, the format will be parseable by anything compliant with any standard of these two, and you only need to handle a very small set of branches.
11 comments
[ 3.2 ms ] story [ 43.6 ms ] threadI consider it the "Markdown for time". It is human-friendly and computer-friendly at the same time. It is supported by many languages and databases. It is so elegant and common that even though it is not part of a standard, LLMs started to use it when writing answers:
Me: SQLite: Add 1 day and 3 hours to a date.
Perplexity: SELECT DATETIME('2025-09-07 07:51:00', '+1 day', '+3 hours');
https://en.cppreference.com/w/c/chrono/strftime
Man page strftime shows,
%F Equivalent to %Y-%m-%d (the ISO 8601 date format). (C99) %T The time in 24-hour notation (%H:%M:%S). (SU)
The Op linked page did not recognise these. I tried with the "%FT%T%z" which works fine with date and strftime().
I've probably used %F and %T about 20 years with no issues linux, bsd and mac that I wrote code over the years.
BTW, It would be nice to see some reference or comparison how systems stdlib implementations match with these standards if there is one.
One gripe I've got with RFC3999 and it's not nice to have the semicolon in filename if you intend to use it file or directory name. As it conflicts and easily becoome issue when not quoted while using rsync or any command that thinks colon (:) separates and indicates host name. I'm not sure if colon would cause issues with windows but there is chance it could as it's used indicating device name.
ps. I had to implement many stdlib time.h defined functions my own between -89 - 92 for my then work as Turbo C 2.0 and 3.0/3.1 did not implement these. I recall that last time I touched these and fixed issues was when I got P.J. Plaugers The Standard C Library book when it was brand new -92. When earlier proprietary C-compliers libraries sources had not been available, that Plaugers book was was great help for many :)
when I worked on datetime portion of Katproto, I had this link pinned for quite some time as a reference! ah, nostalgia...
also, post factum, I find this technical decision actually good - instead of supporting all possible variations of ISO 8601 or all the variations of RFC 3339, why not just support the intersection? that way, the format will be parseable by anything compliant with any standard of these two, and you only need to handle a very small set of branches.