News for hackers. Stuff that matters.
Re:The future of 32-bit support in the kernel by idoubtit on Monday September 01, 2025 @04:43PM (#45096443)
> I also wish that the world would settle on a sane date-time format like the ISO 8601

IIRC, in most countries the native format is D-M-Y (with varying separators), but some Asian countries use Y-M-D. Since those formats are easy to distinguish, that's no problem. That's why Y-M-D is spreading in Europe for official or technical documents.

There's mainly one country which messes things up...

Re:The future of 32-bit support in the kernel by tavavex on Monday September 01, 2025 @06:29PM (#45097172)
YYYY-MM-DD is also the official date format in Canada, though it's not officially enforced, so outside of government documents you end up seeing a bit of all three formats all over the place. I've always used ISO 8601 and no one bats an eye, and it's convenient since YYYY-DD-MM isn't really a thing, so it can't be confused for anything else, unlike the other two formats.
Re:The future of 32-bit support in the kernel by zahlman on Monday September 01, 2025 @07:07PM (#45097401)
YMD has caught on, I think, because it allows for the numbers to be "in order" (not mixed-endian) while still having the month before the day which matches the practice for speaking dates in (at least) the US and Canada.
Re:The future of 32-bit support in the kernel by adgjlsfhk1 on Monday September 01, 2025 @08:48PM (#45097985)
The primary reason for YMD is that DDMMYYYY is ambiguous with MMDDYYYY
Re:The future of 32-bit support in the kernel by christophilus on Monday September 01, 2025 @09:09PM (#45098082)
It is also sortable, which I think is the real advantage.
Re:The future of 32-bit support in the kernel by privatelypublic on Monday September 01, 2025 @09:49PM (#45098295)
As ling as you pad to two characters!
Re:The future of 32-bit support in the kernel by globular-toast on Tuesday September 02, 2025 @04:42AM (#45100511)
I used to think this was really important, but what's the use case here?

If I'm writing a document for human consumption then why would I expect the dates to be sortable by a naive string sorting algorithm?

On the other hand, if it's data for computer consumption then just skip the complicated serialisation completely and dump the Unix timestamp as a decimal. Any modern data format would include the ability to label that as a timestamp data type. If you really want to be able to "read" the data file then just include another column with a human-formatted timestamp, but I can't imagine why in 2025 I would be manually reading through a data file like some ancient mathematician using a printed table of logarithms.

Re:The future of 32-bit support in the kernel by Majestic121 on Tuesday September 02, 2025 @05:10AM (#45100697)
> If I'm writing a document for human consumption then why would I expect the dates to be sortable by a naive string sorting algorithm?

If you're naming a document for human consumption, having the files sorted by date easily without relying on modification date (which is changed by fixing a typo/etc...) is pretty neat

Re:The future of 32-bit support in the kernel by bombcar on Tuesday September 02, 2025 @06:59AM (#45101371)
This is exactly it - file name is easy to control and sort on; creates date and modified date are (for most users) random and uncontrolled.
Re:The future of 32-bit support in the kernel by globular-toast on Wednesday September 03, 2025 @01:55AM (#45112626)
So you can't sort by name, author etc? One sort key? What year is it?!
Re:The future of 32-bit support in the kernel by christophilus on Monday September 01, 2025 @09:08PM (#45098077)
I live in that country, and I am constantly messing up date forms. My brain always goes yyyy-mm-dd. If I write it out, September 1st, 2025, I get it in the “right” order. But otherwise, especially if I’m tired, it’s always in a sortable format.
Re:The future of 32-bit support in the kernel by rocqua on Tuesday September 02, 2025 @01:52AM (#45099545)
8601, when used fully according to spec sucks. It makes today 20250902. It doesn't have seperators. And for adding a time it gets even less readable.

Its a serialization and machine communication format. And that makes me sad. Because YYYY-MM-DD is a great format, without a good name.

Re:The future of 32-bit support in the kernel by account42 on Tuesday September 02, 2025 @04:08AM (#45100324)
It does have a good name: RFC 3339. Unlike the ISO standard, that one mandates the "-" separators. Meanwhile it lets you substitute a space for the ugly "T" separator between date and time:

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

Re:The future of 32-bit support in the kernel by em500 on Tuesday September 02, 2025 @03:49AM (#45100221)
YYYY-MM-DD is ISO8601 extended format, YYYYMMDD is ISO8601 basic format (section 5.2.1.1 of ISO8601:2000(E)[1]). It's fully according to spec, and neither format takes precedence over the other.

[1] https://www.pvv.org/~nsaa/8601v2000.pdf

Re:The future of 32-bit support in the kernel by Y_Y on Tuesday September 02, 2025 @06:51AM (#45101307)
I always like the compromise of the M/D/M system popularised by the British documentary series Look Around You, e.g. "January the fourth of March".