The T makes it hard to visually parse. Whenever I try to read a timestamp using the T I have to scan it very carefully to see the date-time boundary. It'sWasWifWweWusedWaW"W"WtoWdenoteWwordWboundaries. I beg you people, use a space:
I agree on the 'T' being harder to read, but dislike the use of a space as it makes it ill-suited for use in a filename, and would allow word-wrapping to occur between the two sections. I'd much rather they had used an underscore instead of a 'T'.
Windows does not allow the colon (":") in filenames, so you can't use the ISO date-time format in filenames anyway.
RFC 3339 notes:
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
I tend to use the space whenever possible.
Note also that ISO 8601 doesn't require the "T" to be uppercase. A lowercase "t" might be slightly more readable: 2021-11-21t15:10:35
Best to avoid spaces in file names even if the OS allows it (hell, you can put a new line in file names in Linux and I believe Mac OS but that's a terrible idea) because many programs will exhibit major error states if they end up processing these names due to assumptions about file names.
And thats the reason why we should use more spaces and other special characters in filenames at every public used places. Thats the only way this bugs of lazy and stupid software developers getting fixed finally.
The principled stance is nice (and I agree with it generally) but sometimes you just need to get work done and not have to rely on trying to get some developer to fix something. Fully agreed though that it's lazy programming if an application can't deal with spaces.
Which I've always considered a weird anachronism, because 'space' isn't represented any differently than any other character, U+0020, unless you really want to get into the variety of "whitespace" elements. Same with newlines. It's all bytes.
Mostly because the browser Javascript API for Date is kind of crap for dealing with timezone info. There are some efforts to standardize on a better API, but it's going to take time to migrate.
How do you know what time zone to convert it FROM? Unlike epoch time (Unix time in milliseconds or seconds), "2021-11-21T15:10:35" doesn't automatically mean UTC without a "Z" or "+0" at the end. Without the time offset, that timestamp could be in any of the world's timezones. There's no way to know what moment in time was actually stored/meant.
Even if the user set it in one time zone, if we store it without a proper offset (and preferably a locale), we cannot properly account for the user traveling to another place, daylight savings time, government time adjustments, leap time, etc. These complexities compound off each other and make proper scheduling and debugging time issues really, REALLY hard later on.
In the twenty years or so that I've been doing web dev, datetime is probably the single biggest gotcha I've seen developers (including myself) stumble into. Part of this is because the standard JS datetime handling is atrocious compared to any other language I've worked in. It doesn't really natively handle time zones well, and well carelessly cast them back and forth if you're not careful.
Moment and Luxon can help with this, lighter libs like date-fns can too with the right extensions, but out of the box JS is going to fuck it up. I promise. Another choice is to just use milliseconds to store everything, and convert that to the user's timezone only at the time of display. Every timestamp is stored as an epoch, and every user has their time zone (not just offset, because of daylight savings) recorded with their profile. Doing those two simple things can avoid most of the landmines.
Surely when someone posts content, that date/time that happens is captured by the server in epoch time.
And javascript natively converts epoch time to whatever timezone the client has set. If your user-agent (aka browser) is working on New York time, but you're in Tokyo, well, I'm not sure who else you have to blame but yourself if it shows you New York time when you didn't want that.
How do you determine the viewer's timezone? A lot of apps try to find your timezone and it works fine until you travel abroad to a country with a different timezone.
If your own user-agent or OS is working on the wrong timezone, that's your fault.
A website/app shouldn't have to find your timezone. It should use whatever one you've set. If you've set your timezone to one you didn't want, I'm not sure what you'd expect other software is meant to do about that. Fix your config.
If you're not formatting a numerical date in the user's preferred date format then you're probably not localizing the month name to the user's language either.
I think irrational’s point is that it’s trivial for any viewer, no matter the locality, to identify the date if there is no longer any ambiguity between date and month.
I thought ISO 8601 allowed both unqualified times (e.g. "2023-10-14T19:21:45"), which are assumed to be local times, and qualified times (e.g. "2023-10-14T19:21:45−01:00"). Which one is used is then a choice left up to an individual program.
No: 1) unfortunately ambiguous with also widely used MM/DD/YYYY, 2) cannot be naturally sorted, the order does not go from the most significant to the least significant, especially when appended with HH:MM:SS.
Sorry, can't sort it in a column. I'm totally uninterested in everything that ever happened the first of january. I want to see the mails from last night on top.
