100 anos de diferença no time_point após a serialização usando std::put_time e std::get_time

Eu diria que o principal problema é usar "%X %x" como formato. De acordo com cppreference , isso depende da localidade. Isso significa que você obterá representações diferentes dependendo de onde for executado ou até mesmo, como você pode ver, diferentes versões do compilador. Para o formato, eu recomendaria "%Y-%m-%d %H:%M:%S"evitar o comportamento dependente da localidade.

Eu também recomendaria o horário local, que depende do fuso horário. std::gmtimeseria melhor.

Veja os resultados em https://godbolt.org/z/osT9741vz

Você não deseja serializar uma data/hora para um formato dependente de localidade. Em vez disso, serialize algo que seja independente da localidade, como milissegundos desde a época:

// Serialize a time_point to a string
std::string serialize(const std::chrono::system_clock::time_point& time_point) {
    auto duration_since_epoch = time_point.time_since_epoch();
    auto milliseconds_since_epoch = std::chrono::duration_cast<std::chrono::milliseconds>(duration_since_epoch).count();
    return std::to_string(milliseconds_since_epoch);
}

// Deserialize a string to a time_point
std::chrono::system_clock::time_point deserialize(const std::string& str) {
    std::istringstream iss(str);
    long long milliseconds_since_epoch;
    iss >> milliseconds_since_epoch;
    auto duration_since_epoch = std::chrono::milliseconds(milliseconds_since_epoch);
    return std::chrono::system_clock::time_point(duration_since_epoch);
}

int main() {
    // Get the current time
    auto now = std::chrono::system_clock::now();

    // Serialize the time to a string
    std::string serialized_time = serialize(now);
    std::cout << "Serialized time: " << serialized_time << std::endl;

    // Deserialize the string back to a time_point
    auto deserialized_time = deserialize(serialized_time);
    std::cout << "Deserialized time: " << std::chrono::duration_cast<std::chrono::milliseconds>(deserialized_time.time_since_epoch()).count() << " milliseconds since epoch" << std::endl;

    return 0;
}

Demonstração ao vivo

O problema é como interpretar o ano de dois dígitos. Quando o ser humano vê, '80ele assume o ano de 1980. E quando vê '22, ele assume o ano de 2022.

Agora, esse preconceito humano não foi refletido na versão mais antiga da biblioteca, então std::get_timeapenas assume que o ano de dois dígitos se refere a 1900. A nova versão da biblioteca tenta equilibrar isso e, dependendo do valor de dois dígitos, ela assume 1900 ou 2000.

Aqui está uma demonstração do problema, incluindo uma possível solução alternativa para o gcc 8.5: https://godbolt.org/z/MThhac943

struct Param
{
    std::string fullTime;
    std::string shortTime;
};

class MagicTimeStringTest : public testing::TestWithParam<Param>
{
public:
    using clock = std::chrono::system_clock;
    
    static clock::time_point parse(std::string in, std::string format)
    {
        std::istringstream stream(in);
        std::tm t = {};
        EXPECT_TRUE(stream >> std::get_time(&t, format.c_str()));
#ifdef WORAROUND
        if (t.tm_year < 69) {
            t.tm_year += 100;
        }
#endif
        return clock::from_time_t(std::mktime(&t));
    }

    static std::string toString(clock::time_point p)
    {
        std::ostringstream stream;
        auto t = clock::to_time_t(p);
        stream << std::put_time(std::localtime(&t), "%a %b %d %T %Y");
        return stream.str();
    }
};

TEST_P(MagicTimeStringTest, BarReturnsExpectedValue)
{
    auto fromShort = parse(GetParam().shortTime, "%x %X");
    auto fromFull = parse(GetParam().fullTime, "%b %d %T %Y");

    EXPECT_EQ(fromShort, fromFull) << toString(fromShort) << '\n' << toString(fromFull);

    auto diffHours = std::chrono::duration_cast<std::chrono::hours>(fromFull - fromShort).count();
    EXPECT_EQ(diffHours, 0);
}

const Param data[] {
    {"Feb 22 16:51:30 1994", "02/22/94 16:51:30"},
    {"Feb 22 16:51:30 1974", "02/22/74 16:51:30"},
    {"Feb 22 16:51:30 1970", "02/22/70 16:51:30"},
    {"Feb 22 16:51:30 1969", "02/22/69 16:51:30"},
    {"Feb 22 16:51:30 2068", "02/22/68 16:51:30"}, // note here change in test data it is 2068 not 1968
    {"Feb 22 16:51:30 2024", "02/22/24 16:51:30"},
};

INSTANTIATE_TEST_SUITE_P(StackOverflow, MagicTimeStringTest, testing::ValuesIn(data));

Seria bom encontrar uma explicação desse comportamento na documentação. Eu não ficaria surpreso se a fronteira entre a mudança de séculos se movesse da mesma forma que se move com o tempo atual, portanto o futuro 2100 é abordado.

Editar:

Com a ajuda de perplexity.ai consegui encontrar alguma documentação que explica esse comportamento (google e bing falharam nesta pesquisa):

data

Se o século não for especificado, então os valores no intervalo [69,99] deverão referir-se aos anos de 1969 a 1999 inclusive, e os valores no intervalo [00,68] deverão referir-se aos anos de 2000 a 2068 inclusive. O ano atual será o padrão se yy for omitido.

Observação:

Espera-se que em uma versão futura do IEEE Std 1003.1-2001 o século padrão inferido a partir de um ano de 2 dígitos mude. (Isso se aplicaria a todos os comandos que aceitam um ano de 2 dígitos como entrada.)

Portanto, esse comportamento é padronizado IEEE Std 1003.1-2001e espera-se que seja atualizado no futuro. Até agora não consegui encontrar documentos disponíveis publicamente com este padrão.

Howard Hinnant forneceu um ótimo link para o padrão C++ 20 como comentário:

[tempo.parse]

%y

Os dois últimos dígitos decimais do ano .

Se o século não for especificado de outra forma (por exemplo, com %C), presume-se que os valores no intervalo [69, 99] se referem aos anos de 1969 a 1999, e os valores no intervalo [00, 68] se referem aos anos de 1969 a 1999. os anos de 2000 a 2068 .

O comando modificado % N y especifica o número máximo de caracteres a serem lidos .

Se N não for especificado, o padrão será 2 .

Zeros à esquerda são permitidos, mas não obrigatórios .

Os comandos modificados %Ey e %Oy interpretam a representação alternativa do código do idioma .