`date::parse` ignores `%p` (AM/PM) when parsing `sys_time` with `%I:%M:%S %p %z`

[matigarciadev]

Summary

Parsing 12‑hour times with AM/PM directly into date::sys_time ignores %p: PM inputs produce the same UTC result as AM. The C++ locale facet appears correct (std::get_time handles AM/PM). Using %r instead of %I:%M:%S %p works, so this looks specific to %I…%p in date::parse/from_stream for sys_time when combined with %z/%Ez.

Minimal repro (fails with %I:%M:%S %p)

main.cpp

#include <iostream>
#include <sstream>
#include <string>
#include <chrono>
#include <locale>
#include <date/date.h>

template <typename Dur>
void test(const std::string& s, const std::string& fmt) {
    std::istringstream in{s};
    in.imbue(std::locale("en_US.utf8")); // AM/PM facet
    date::sys_time<Dur> tp{};
    in >> date::parse(fmt.c_str(), tp);
    if (!in) {
        std::cerr << "Parse failed. fmt='" << fmt << "' input='" << s << "'\n";
        return;
    }
    std::cout << s << "  ->  " << date::format("%FT%TZ", tp) << '\n';
}

int main() {
    using seconds = std::chrono::seconds;

    test<seconds>("Sep 16, 2025 10:29:51 PM -0300",
                  "%b %d, %Y %I:%M:%S %p %z");

    test<seconds>("Sep 16, 2025 10:29:51 PM -03:00",
                  "%b %d, %Y %I:%M:%S %p %Ez");

    test<seconds>("Sep 16, 2025 10:29:51 AM -0300",
                  "%b %d, %Y %I:%M:%S %p %z");
}

Actual output (incorrect)

Sep 16, 2025 10:29:51 PM -0300  ->  2025-09-16T13:29:51Z
Sep 16, 2025 10:29:51 PM -03:00  ->  2025-09-16T13:29:51Z
Sep 16, 2025 10:29:51 AM -0300  ->  2025-09-16T13:29:51Z

Expected output

Sep 16, 2025 10:29:51 PM -0300  ->  2025-09-17T01:29:51Z
Sep 16, 2025 10:29:51 PM -03:00  ->  2025-09-17T01:29:51Z
Sep 16, 2025 10:29:51 AM -0300  ->  2025-09-16T13:29:51Z

Control repro (works with %r)

main_r.cpp

#include <iostream>
#include <sstream>
#include <string>
#include <chrono>
#include <locale>
#include <date/date.h>

template <typename Dur>
void test(const std::string& s, const std::string& fmt) {
    std::istringstream in{s};
    in.imbue(std::locale("en_US.utf8"));
    date::sys_time<Dur> tp{};
    in >> date::parse(fmt.c_str(), tp);
    if (!in) {
        std::cerr << "Parse failed. fmt='" << fmt << "' input='" << s << "'\n";
        return;
    }
    std::cout << s << "  ->  " << date::format("%FT%TZ", tp) << '\n';
}

int main() {
    using seconds = std::chrono::seconds;

    test<seconds>("Sep 16, 2025 10:29:51 PM -0300",
                  "%b %d, %Y %r %z");

    test<seconds>("Sep 16, 2025 10:29:51 PM -03:00",
                  "%b %d, %Y %r %Ez");

    test<seconds>("Sep 16, 2025 10:29:51 AM -0300",
                  "%b %d, %Y %r %z");
}

Actual output (correct)

Sep 16, 2025 10:29:51 PM -0300  ->  2025-09-17T01:29:51Z
Sep 16, 2025 10:29:51 PM -03:00  ->  2025-09-17T01:29:51Z
Sep 16, 2025 10:29:51 AM -0300  ->  2025-09-16T13:29:51Z

Facet sanity check (std lib handles %p correctly)

diag.cpp

#include <locale>
#include <iomanip>
#include <sstream>
#include <ctime>
#include <iostream>

int main() {
    std::locale loc("en_US.utf8");

    // %p formats correctly
    std::ostringstream os; os.imbue(loc);
    std::tm tm{}; tm.tm_hour = 13;
    os << std::put_time(&tm, "%p");
    std::cout << "put_time(%p) for 13:00 -> '" << os.str() << "' (expect 'PM')\n";

    // get_time parses AM/PM correctly
    auto parse = [&](const char* s){
        std::tm t{}; std::istringstream is(s); is.imbue(loc);
        is >> std::get_time(&t, "%I:%M:%S %p");
        std::cout << "get_time('" << s << "') -> tm_hour=" << t.tm_hour << "\n";
    };
    parse("10:29:51 AM"); // -> 10
    parse("10:29:51 PM"); // -> 22
    parse("12:00:00 AM"); // -> 0
    parse("12:00:00 PM"); // -> 12
}

Observed

put_time(%p) for 13:00 -> 'PM' (expect 'PM')
get_time('10:29:51 AM') -> tm_hour=10
get_time('10:29:51 PM') -> tm_hour=22
get_time('12:00:00 AM') -> tm_hour=0
get_time('12:00:00 PM') -> tm_hour=12

Environment

Compiler: GCC 13.3.0
$ gcc --version
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

libc: glibc 2.39
$ ldd --version
ldd (Ubuntu GLIBC 2.39-0ubuntu8.5) 2.39

Locales available (excerpt):
$ locale -a
C
C.utf8
…
en_US.utf8
…

• en_US.utf8 loads successfully and is used in the tests above.
• date version tested: v3.0.4 (also reproducible with v3.0.1).

Notes / Workarounds

• Using %r (12‑hour time with AM/PM) instead of %I:%M:%S %p works correctly.
• Alternatively, normalize AM/PM to 24‑hour in the input and parse with %H:%M:%S %z/%Ez.

Ask

Is %p being dropped when parsing sys_time with %I…%p along with %z/%Ez? Any fix or guidance would be appreciated.

[HowardHinnant]

Thanks for this bug report. I'm not able to reproduce it, however I have a good idea what the bug is. If you could test this one-line addition and let me know if it fixes it for you, I would really appreciate it:

diff --git a/include/date/date.h b/include/date/date.h
index 53c4d1c..b55cf65 100644
--- a/include/date/date.h
+++ b/include/date/date.h
@@ -7187,6 +7187,7 @@ from_stream(std::basic_istream<CharT, Traits>& is, const CharT* fmt,
                         int tp = not_a_ampm;
 #if !ONLY_C_LOCALE
                         tm = std::tm{};
+                        tm.tm_isdst = -1;
                         tm.tm_hour = 1;
                         ios::iostate err = ios::goodbit;
                         f.get(is, nullptr, is, err, &tm, command, fmt+1);

[matigarciadev]

Thanks for the fast turnaround and the suggested.

I applied the patch to date.h (v3.0.4) exactly as you proposed:

#if !ONLY_C_LOCALE
     tm = std::tm{};
+   tm.tm_isdst = -1;   // added
     tm.tm_hour = 1;
     ios::iostate err = ios::goodbit;
     f.get(is, nullptr, is, err, &tm, command, fmt+1);

Result: still reproducible (PM == AM)
With the patch in place (and ONLY_C_LOCALE=0), the minimal repro still produces the same UTC for AM and PM when parsing directly into date::sys_time with %z/%Ez:

"Sep 16, 2025 10:29:51 PM -0300"  ->  2025-09-16T13:29:51Z
"Sep 16, 2025 10:29:51 PM -03:00" ->  2025-09-16T13:29:51Z
"Sep 16, 2025 10:29:51 AM -0300"  ->  2025-09-16T13:29:51Z

Test code (unchanged except for the patched header)

std::locale loc("en_US.utf8");
std::istringstream in{s};
in.imbue(loc);
date::sys_time<std::chrono::seconds> tp{};
in >> date::parse("%b %d, %Y %I:%M:%S %p %z", tp);   // or %Ez

Controls that still pass

• std::get_time with "%I:%M:%S %p" parses AM/PM correctly (10 PM → 22, 12 AM → 0, 12 PM → 12).
• Using "%r" instead of "%I:%M:%S %p" does distinguish AM vs PM when combined with %z/%Ez and sys_time.
• Defining ONLY_C_LOCALE=1 also fixes the issue for "%I:%M:%S %p %z/%Ez".
• Trying both std::locale::classic() and "en_US.utf8" yields the same behavior (with the patch applied): PM == AM in the facet‑based path.

Hypothesis
Given that %r works, ONLY_C_LOCALE=1 works, and std::get_time on its own works, it seems the facet‑based from_stream path for sys_time + %I…%p + %z/%Ez is still not propagating the meridiem information into the final sys_time in my setup. If there are multiple %p handling sites/branches in from_stream, perhaps my format is taking a different branch than the one we just patched.

I’ll keep this project ready to re‑test patches as needed.

[HowardHinnant]

Thanks for your feedback.

I currently don't have a good answer. My best suggestion so far is to go with ONLY_C_LOCALE=1, but this will ignore locales that use something besides AM/PM for the designations. I will keep looking for a better fix than that.

[HowardHinnant]

I've been looking into this further. At this time, I don't see a way to implement this on gcc. The gcc libstdc++ library demands that for a %p to be processed, a %I must also be processed in the same parse. But at the implementation level in date, it can only ask the C++ lib to process a single format flag at a time. The clang and MS std::libs don't have this restriction, and so the current date implementation works on those platforms.

I want to stress that this is not a bug in the gcc std::lib. Rather it is a hole in the C++11 API of std::time_get that prevents a portable implementation of what the date lib needs to do. And even ifdefing on gcc, I don't currently see a practical way of parsing %p using the gcc platform.

The right fix to this problem is to move it into the std::lib implementor's hands (standardize the API). Mission accomplished. But that answer sucks for clients who can not yet migrate to an environment that implements C++20 chrono.

https://gcc.godbolt.org/z/nK558zWej

gcc 14 implements the full C++20 chrono spec. If you can use gcc 14 (or higher) use std::chrono::parse in place of date::parse.

For gcc 13 I recommend compiling the date lib with ONLY_C_LOCALE=1 which means the date lib will assume the 'C' locale is always the right locale to use.