<chrono>: Parsing "00:00:60" as `utc_time` incorrectly returns 00:00:59.0000000

[statementreply]

Command-line test case

C:\Users\He\source\test>type chronat.cpp

#include <chrono>
#include <iostream>
#include <sstream>
#include <stdexcept>
#include <string>

using namespace std;
using namespace std::chrono;

int main() {
    try {
        utc_clock::time_point t;
        if (istringstream{"2021-08-28 00:00:60"} >> parse("%F %T"s, t)) {
            cout << t << "\n";
        } else {
            cout << "parse failed\n";
        }
    } catch (const exception& e) {
        cout << "error: " << e.what() << "\n";
    }
    return 0;
}

C:\Users\He\source\test>cl /EHsc /W4 /WX /std:c++20 chronat.cpp
用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.32.31328 版
版权所有(C) Microsoft Corporation。保留所有权利。

chronat.cpp
Microsoft (R) Incremental Linker Version 14.32.31328.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:chronat.exe
chronat.obj

C:\Users\He\source\test>.\chronat.exe
2021-08-28 00:00:59.0000000

Expected behavior
Prints either "parse failed" or "2021-08-28 00:00:59.9999999", depending on the design choice.

STL version
Microsoft Visual Studio Community 2022 (64 位) - Preview
版本 17.2.0 Preview 5.0

[PallHaraldsson]

FYI "60" is correct (for leap second, at least with the T/ISO format you're not using, and likely always?) according to https://en.wikipedia.org/wiki/ISO_8601#Times

So I guess you can close this issue.

Not all support it, seeing this issue made me think so I asked, and pointed out, here:
https://discourse.julialang.org/t/parsing-datetime-what-should-be-the-default-s/80428

There's an answer, with a question regarding it there.

[statementreply]

FYI "60" is correct (for leap second, at least with the T/ISO format you're not using, and likely always?)

For a valid leap second (e.g. istringstream{"2016-12-31T23:59:60Z"} >> parse("%FT%TZ"s, t)), the result is correct (2016-12-31 23:59:60.0000000).

However, 2021-08-28T00:00:60Z doesn't physically exist, and cannot be represented as a utc_clock::time_point value. Imo either of the following behaviors sounds reasonable:

1. Reject the input.
2. Accept the input, parse it to the closest representable value, that is 2021-08-28T00:00:59.9999999Z.

The current behavior is returning 2021-08-28T00:00:59.0000000Z, which I think is incorrect.

[PallHaraldsson]

Sorry it seems actually parsing e,g, "xx:00:60" is always wrong.

I see in Java code:
https://gist.github.com/dehora/9b2ce8bac22d1b37393d8b4f7c9eb7aa

if (raw.contains(":59:60")) {

Found at https://stackoverflow.com/questions/48009870/parsing-localtime-with-leap-second

I'm not sure what's demanded by the standards, up you should round down, or maybe up (then would hit next day even year).

[MattStephanson]

My opinion is that there is no corresponding utc_time, so this parse should fail per [time.parse]/16. The issue is that the logic to check for a valid leap second is only taken if the hour and minute equal 23 and 59:

STL/stl/inc/chrono

Lines 3492 to 3495 in 39332e1

	if (_Leap != _LeapSecondRep::_None) {
	if (_Hour_24 == 23 && _Minute == 59 && _Second >= 59) {
	// It's possible that the parsed time doesn't exist because (a) _Seconds == 60 and there *isn't* a
	// leap second insertion or (b) _Seconds == 59 and there *is* a leap second subtraction.

Off the top of my head, I think it would be easiest to fix slightly earlier, here:

STL/stl/inc/chrono

Lines 3388 to 3390 in 39332e1

	const auto _Time_out_of_range{
	_For_time_point
	&& (_Out_of_range(_Second, 0, 60) || _Out_of_range(_Minute, 0, 59) || _Out_of_range(_Hour_24, 0, 23))};

where the upper bound for _Second can be changed to (_Hour_24 == 23 && _Minute == 59) ? 60 : 59.