[CLOSED] ISO 8601 timestamps

[avk]

Is this the correct value in ISO 8601 terms: "2022-12-31T23:59:60Z"?
TryISOStrToDateTime() claims it isn't.

[paweld]

"2022-12-31T23:59:60Z"

the range of seconds can be from 0 to 59

[Thaddy]

And TryISOStrToDateTime is correct....
"2022-12-31T23:59:60Z"
should be
"2023-01-01T00:00:00Z"
The ISO 8601 resolution is in seconds.

[Kays]

Is this the correct value in ISO 8601 terms: "2022-12-31T23:59:60Z"?

Yes, it is. I mean, there was no leap second, but I don’t think ISO 8601 cares about validity, because the decision to introduce a leap second is beyond the ISO committee’s control.

the range of seconds can be from 0 to 59

2016-12-31T23:59:60Z should be accepted though. As far as I looked into it, the implicitly used tryEncodeTime thinks a seconds value > 59 was absolutely illegal.

The ISO 8601 resolution is in seconds.

ISO 8601 does permit an arbitrary number of decimal digits. A valid datum:
2023-01-16T20:04:25.327696787123788+00:00
However, this will also be rejected by tryISOStrToDateTime.

[avk]

Thank you all. The problem does not seem to be important to the Free Pascal community.

[Thaddy]

2023-01-16T20:04:25.327696787123788+00:00
However, this will also be rejected by tryISOStrToDateTime.

Because fractions of a second are not part of ISO 8601. Do not make assumptions. READ IT.
In this case it did not matter either way, because 60 was already an overflow.
Fractions of a second above 59

[MarkMLl]

Because fractions of a second are not part of ISO 8601. Do not make assumptions. READ IT.
In this case it did not matter either way, because 60 was already an overflow.
Fractions of a second above 59

Thaddy, you do have a most endearing way of getting people to read documents on your behalf.

4.2.2.4 Representations with decimal fraction
If necessary for a particular application a decimal fraction of hour, minute or second may be included.
If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal
fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the
comma [,] or full stop [.]. Of these, the comma is the preferred sign. If the magnitude of the number is
less than unity, the decimal sign shall be preceded by two zeros in accordance with 3.6.

MarkMLl

[Thaddy]

60 was already an overflow, Mark...

[MarkMLl]

The example Kays gave, which you appear to take exception to, isn't. Or didn't you bother to read that either?

Besides:

— second is represented by two digits from [00] to [60]. The representation of the second by [60] is only allowed to indicate a positive leap second or an instant within that second.

i.e. 60.999 etc. isn't ruled out by the standard.

MarkMLl

[Thaddy]

Yes it is, following the rule. You can't live tomorrow when you are dead.

[MarkMLl]

A leap second isn't tomorrow. Or do you believe that February 29th is in March?

Come on Thaddy, you can do better than this...

MarkMLl

[Thaddy]

What a nonsense. Fractions overflow on and after 60 seconds. And the example provided by avk is also a special case (year bounds) and my answer is conform ISO 8601. You know that.
TryISOStrToDateTime() is ISO 8601 conformant. Period.

[MarkMLl]

Disagree.

MarkMLl

[PascalDragon]

What a nonsense. Fractions overflow on and after 60 seconds. And the example provided by avk is also a special case (year bounds) and my answer is conform ISO 8601. You know that.
TryISOStrToDateTime() is ISO 8601 conformant. Period.

ISO 8601-1:2016, 2.2.2 explicitly states the following:

An inserted second is called positive leap second and an omitted second is called negative leap second. A positive leap second is inserted between [23:59:59Z] and [24:00:00Z] and can be represented as [23:59:60Z].

And 4.2.1 states this:

second is represented by two digits from [00] to [60]. The representation of the second by [60] is allowed only to indicate a positive leap second or an instant within that second

Delphi's ISO8601ToDate handles it as such as well.

Is this the correct value in ISO 8601 terms: "2022-12-31T23:59:60Z"?
TryISOStrToDateTime() claims it isn't.

Please report a bug.

[avk]

Okay, done.