### Bookstore

 Computer Math and Games in Pascal (preview) Lazarus Handbook

### Author Topic: [CLOSED] ISO 8601 timestamps  (Read 1004 times)

#### avk

• Hero Member
• Posts: 729
##### [CLOSED] ISO 8601 timestamps
« on: January 16, 2023, 04:18:26 pm »
Is this the correct value in ISO 8601 terms: "2022-12-31T23:59:60Z"?
TryISOStrToDateTime() claims it isn't.
« Last Edit: January 17, 2023, 05:14:36 pm by avk »

#### paweld

• Hero Member
• Posts: 627
##### Re: ISO 8601 timestamps
« Reply #1 on: January 16, 2023, 04:32:41 pm »
Quote
"2022-12-31T23:59:60Z"
the range of seconds can be from 0 to 59
Best regards / Pozdrawiam
paweld

• Hero Member
• Posts: 12933
##### Re: ISO 8601 timestamps
« Reply #2 on: January 16, 2023, 04:48:32 pm »
And TryISOStrToDateTime is correct....
"2022-12-31T23:59:60Z"
should be
"2023-01-01T00:00:00Z"
The ISO 8601 resolution is in seconds.
« Last Edit: January 16, 2023, 04:58:33 pm by Thaddy »
In memory of Gordon Moore  (January 3, 1929 – March 24, 2023) Just double the heaven every two years from now.

#### Kays

• Sr. Member
• Posts: 494
• Whasup!?
##### Re: ISO 8601 timestamps
« Reply #3 on: January 16, 2023, 09:04:54 pm »
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.
« Last Edit: January 16, 2023, 09:12:43 pm by Kays »
Yours Sincerely
Kai Burghardt

#### avk

• Hero Member
• Posts: 729
##### Re: ISO 8601 timestamps
« Reply #4 on: January 17, 2023, 05:13:47 pm »
Thank you all. The problem does not seem to be important to the Free Pascal community.

• Hero Member
• Posts: 12933
##### Re: ISO 8601 timestamps
« Reply #5 on: January 17, 2023, 05:31:15 pm »
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
« Last Edit: January 17, 2023, 05:33:15 pm by Thaddy »
In memory of Gordon Moore  (January 3, 1929 – March 24, 2023) Just double the heaven every two years from now.

#### MarkMLl

• Hero Member
• Posts: 5922
##### Re: ISO 8601 timestamps
« Reply #6 on: January 17, 2023, 05:40:15 pm »
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.

Quote
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

• Hero Member
• Posts: 12933
##### Re: [CLOSED] ISO 8601 timestamps
« Reply #7 on: January 17, 2023, 05:50:34 pm »
60 was already an overflow, Mark...
In memory of Gordon Moore  (January 3, 1929 – March 24, 2023) Just double the heaven every two years from now.

#### MarkMLl

• Hero Member
• Posts: 5922
##### Re: [CLOSED] ISO 8601 timestamps
« Reply #8 on: January 17, 2023, 05:59:02 pm »
The example Kays gave, which you appear to take exception to, isn't. Or didn't you bother to read that either?

Besides:

Quote
— 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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

• Hero Member
• Posts: 12933
##### Re: [CLOSED] ISO 8601 timestamps
« Reply #9 on: January 17, 2023, 06:51:41 pm »
Yes it is, following the rule. You can't live tomorrow when you are dead.
In memory of Gordon Moore  (January 3, 1929 – March 24, 2023) Just double the heaven every two years from now.

#### MarkMLl

• Hero Member
• Posts: 5922
##### Re: [CLOSED] ISO 8601 timestamps
« Reply #10 on: January 17, 2023, 07:25:15 pm »
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
« Last Edit: January 17, 2023, 09:14:09 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

• Hero Member
• Posts: 12933
##### Re: [CLOSED] ISO 8601 timestamps
« Reply #11 on: January 18, 2023, 06:19:00 am »
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.
« Last Edit: January 18, 2023, 06:23:25 am by Thaddy »
In memory of Gordon Moore  (January 3, 1929 – March 24, 2023) Just double the heaven every two years from now.

#### MarkMLl

• Hero Member
• Posts: 5922
##### Re: [CLOSED] ISO 8601 timestamps
« Reply #12 on: January 18, 2023, 07:51:10 am »
Disagree.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

#### PascalDragon

• Hero Member
• Posts: 4963
• Compiler Developer
##### Re: [CLOSED] ISO 8601 timestamps
« Reply #13 on: January 18, 2023, 10:46:02 pm »
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:

Quote
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:

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