Even better would be for it to say "November 2021".

Where's the fun in that? Let's design heuristics that work culturally in some parts of the world and be imprecise instead!

What's wrong with 2021-11-21T15:10:35 ?

I’d prefer it to use the month name.

Then it doesn’t matter if you write it

November 12 2012

2012 November 12

12 November 2012

2012 12 November

Etc.

It matters a lot if you try to sort on that column

We're talking about how it's displayed on the frontend, not how it's stored on the backend

One persons front end is another persons back end.

Especially if you're a proctologist.

We use YYYY-MM-DD HH:mm:as on the frontend because it sorts lexicographically, which is useful for interactive tables.

You can use data attributes for that

There’s no need to have the sort value and the display value to be the same to allow sorting.

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.

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.

How would 2012 ноябрь 12 feel to you?

Fine if I set Russian as my langague. I presume Youtube does localization.

So it could also take the preferred datetime format from the locale.

Time portion not being useful I'd say.

You mean 1637507435?

Yes. As God intended when He created the heavens and the earth on January 1, 1970.

The “T”, mostly.

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:

2021-11-21 15:10:35

See how much easier that is?

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'.

Does windows not allow spaces or something? Unix variants seem fine with it.

Programmers hate dealing with whitespace in strings with a burning passion.

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.

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.

Macos allowing leading spaces in file/folder names made for some fun shenanigans on a school laptop with not great grep usage for blocking apps.

Best to combine a carriage return and tab.

    irb> puts “2021-11-21\r\t15:10:35”
    2021-11-21
        15:10:35

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.

Windows does not allow the colon (":") in filenames, so you can't use the ISO date-time format in filenames anyway.

The reason for avoiding spaces in file names is because of broken bash scripts, that don’t quote their arguments. Meaning about 99 out of 100 of them.

Not that avoiding such names solves the problem, it just makes the RCE vulnerability more latent.

Soundly like space-filled names would be a good best practice to force you to harden your scripts.

Microsoft deliberately named it "C:\Program Files" for exactly this reason.

That makes a surprising amount of sense actually

There exist non-breaking spaces for that exact reason.

I prefer stardate

I prefer parsecs since a long long time ago.

But I don't mean to pick a Star Wars / Star Trek fight: I'm bistellar, I love both of them!

It's missing the timezone offset

It's missing the time zone offset /cry

I had to fix so many of these in various databases and frontends, lol

Not used for display purposes though :-)

Why not just display it in the viewers' timezone?

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.

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.

ISO 8601 is so annoying because timezone offsets are now no longer implied

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.

There, even better: 21/11/2021

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.