Receiving SIGABRT on Raspi when trying to parse string to date with either std::get_time or strftime

When I'm parsing a string to date with either std::get_time or strftime I receive a SIGABRT on my RaspberryPi. When I execute the same code on my Ubuntu computer it works fine.

std::get_time example:

#include <chrono>
#include <iomanip>
#include <iostream>

int main() {
    std::stringstream stream;
    stream.str("09:35:44,02-23-2023");
    std::tm tm{};
    const std::string format = "%H:%M:%S,%m-%d-%Y";
    if((stream >> std::get_time(&tm, format.c_str())).fail()) {
        std::cout << "Parsing failed" << std::endl;
    }
    std::cout << std::chrono::seconds(std::mktime(&tm)).count() << std::endl;
}

I tried Raspberrys with Buster and Bulleseye and both fail to execute the code.
My computer running Ubuntu 22.04 executes the example just fine.
I tried to find known issues when parsing dates on arm architecture, but did not find any.

Any help is greatly appreciated!

Edit:
I'm using CLion gcc-Toolchains to compile the program, managed by a cmake file.
I used remote compilation on either of the Raspberrys (both 3b, with either buster or bulleseye), selecting the default gcc and g++ compiler from the bin directory (on buster gcc-8.3.0, cmake 3.16 and bulleseye gcc-10.2.1, cmake 3.18.3). I also tried to crosscompile it on Ubuntu (with Ubuntus arm-linux-gnueabihf-gcc/g++ compilers), but that had different issues if I recall correctly.
I debugged the program in CLion with remote gdb executing it on the raspberry and the SIGABRT happens during the call to std::get_time. I can even see, inspecting tm, that it contains hour, minutes and seconds correctly, but then it seems to stop.

Thanks to everyone commenting and answering so far!

Edit2: I will try to compile and execute the program on a freshly setup Raspberry asap, command line only on the raspberry to rule out any issues with the CLion toolchain.

Edit3: Thanks again for everyone giving input here. Unfortunately the most unsatisfying solution worked. I tried it again today and I just cannot reproduce the error, but it is working now. I just can't figure out what I did wrong last week... Sorry for the hassle!

Your programs works fine on a RaspberryPi 3 running the latest 32 bit version of Raspberry PI OS available here:

<!-- language: lang-none -->
Compatible with:

    All Raspberry Pi models

Raspberry Pi OS with desktop

    Release date: February 21st 2023
    System: 32-bit
    Kernel version: 5.15
    Debian version: 11 (bullseye)
    Size: 924MB

Show SHA256 file integrity hash:ff0ee221581d4f68257f2a78409a16660272a48d3e31b562a8d32a531a335ca2

lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

uname -a
Linux raspberrypi 5.15.84-v7+ #1613 SMP Thu Jan 5 11:59:48 GMT 2023 armv7l GNU/Linux

g++ --version
g++ (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

g++ -o 75547255 75547255.cpp
./75547255
1677144944

1677144944 is, according to the EpochConverter, the exact value you wanted to convert:

<!-- language: lang-none -->
GMT: Thursday, February 23, 2023 9:35:44 AM
Your time zone: Thursday, February 23, 2023 4:35:44 AM GMT-05:00
Relative: 15 hours ago
As suggested in the comments, you would need to give the same level of details on the exact combination of hardware/operating system/c++ compiler you are using, so that others may attempt reproducing the issue you experimented.

I finally could figure out what I was doing wrong.
First of all I need to apologize to everyone looking at my example, because this is working absolutely fine.
My issue is occurring due to this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896 which is fixed in Ubuntu 22.04 but not Raspbian 11.
I will now either modify the string before parsing or look for a different way to get the date, although the first option seems more promising to me.
Thank you all for helping me with this!