LibreOffice 24.2 Community released

Posted Feb 1, 2024 20:28 UTC (Thu) by dskoll (subscriber, #1630)
In reply to: LibreOffice 24.2 Community released by LightDot
Parent article: LibreOffice 24.2 Community released

I think the version should be the UNIX timestamp of the corresponding commit. I welcome you all to LibreOffice 1706819361

to post comments

LibreOffice 24.2 Community released

Posted Feb 2, 2024 17:09 UTC (Fri) by Wol (subscriber, #4433) [Link] (5 responses)

You made me think of ISO date - LibreOffice 20240202 :-)

Cheers,
Wol

LibreOffice 24.2 Community released

Posted Feb 2, 2024 19:07 UTC (Fri) by joib (subscriber, #8541) [Link] (4 responses)

Per ISO 8601 that should be 2024-02-02! ;)

LibreOffice 24.2 Community released

Posted Feb 2, 2024 21:59 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

Just looked up the ISO (obviously can't get the real text), but apparently leaving out the hyphens is perfectly okay ... :-)

Cheers,
Wol

LibreOffice 24.2 Community released

Posted Feb 2, 2024 23:01 UTC (Fri) by atnot (guest, #124910) [Link] (2 responses)

It's a bit confusing because there's actually two standards. There's the ISO 8601 which defines a huge set of different datetime representations. With or without hyphens, with or without T, two or four digit years, some weird things like ordinal dates, etc. This makes it sort of uselessly vague and since the text isn't publically available, nobody-ish actually adheres to it even if they claim to. Instead what people usually mean when they refer to ISO datetime format is RFC 3339 datetime format, which is just the ISO standard but publically available and with all of the superfluous design-by-committee stuff removed. Since it is the actually useful standard, it's what everything actually uses.

And that one mandates hyphens ;)

LibreOffice 24.2 Community released

Posted Feb 3, 2024 8:37 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

From what I can make out from the summary I read (by someone who's name I recognise, so I trust it), the gist of the standard is you start with the most significant digit (currently 2 for the second millenium) and mustn't leave anything out. Apart from year, everything is two-digit.

So 20240 is actually valid, and unambiguously means any time this year before 1st Nov. Plus the standard delimiters are - and :, if you want UTC you should put T between the date and time, and if there's no indication you assume local time. (You can use Z instead of T, but technically that means the obsolete GMT, which is not quite the same as UTC.)

So it's pretty sensible.

Cheers,
Wol

LibreOffice 24.2 Community released

Posted Feb 3, 2024 16:46 UTC (Sat) by smcv (subscriber, #53363) [Link]

The T and the Z in RFC3339 aren't at the same position in the date/time string, so I think there's some misunderstanding here about their roles, either in the summary you've read or in your interpretation of it.

The example given in RFC3339 is "1985-04-12T23:20:50.52Z", where T is a separator between date and time (nothing to do with time zones, just another separator like : and -), and Z is a shorthand for +00:00, denoting no offset from UTC (and it's UTC not GMT, at least according to the RFC text).

My understanding of ISO 8601 is that its way to write "12th April 1985 at 23:20:50.52 in a time zone I am not specifying here" is to remove the time zone designator entirely, like "1985-04-12T23:20:50.52". RFC3339 specifically doesn't allow an unspecified time zone, though.

The Z is borrowed from an older military standard where times are suffixed with a single letter representing the time zone (spoken using the NATO phonetic alphabet, hence "Zulu time" for UTC), but in RFC3339 the only time zone where this shorthand is allowed is Z, and all the others need to be spelled out as +05:00 or similar (so in particular T is not a valid timezone suffix in RFC3339). As far as I know, the same is true for ISO 8601.