strptime function not following Posix standard for 2 digit years

[maurice1408]

What happens?

The current Posix C standard states "Year without century (00--99). On input, values 00 to 68 are prefixed by 20 and 69 to 99 by 19 -- that is the behaviour specified by the 2004 and 2008 POSIX standards, but they do also say ‘it is expected that in a future version the default century inferred from a 2-digit year will change’."

DuckDb does not seem to be following this standard?

select strptime('570814', '%y%-m%-d');
┌────────────────────────────────┐
│ strptime('570814', '%y%-m%-d') │
│           timestamp            │
├────────────────────────────────┤
│ 2057-08-14 00:00:00            │
└────────────────────────────────┘

To Reproduce

select strptime('570814', '%y%-m%-d');

OS:

Linux Debian Bullseye and macOS

DuckDB Version:

v0.10.2 1601d94

DuckDB Client:

CLI

Full Name:

Maurice Hickey

Affiliation:

Nisos (nisos.com)

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a stable release

Did you include all relevant data sets for reproducing the issue?

Not applicable - the reproduction does not require a data set

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

• Yes, I have

[Mytherin]

Thanks for the report! As you mentioned:

The current Posix C standard states "Year without century (00--99). On input, values 00 to 68 are prefixed by 20 and 69 to 99 by 19

D select strptime('68-01-01', '%y-%m-%d') AS result;
┌─────────────────────┐
│       result        │
│      timestamp      │
├─────────────────────┤
│ 2068-01-01 00:00:00 │
└─────────────────────┘
D select strptime('69-01-01', '%y-%m-%d') AS result;
┌─────────────────────┐
│       result        │
│      timestamp      │
├─────────────────────┤
│ 1969-01-01 00:00:00 │
└─────────────────────┘

This is exactly what DuckDB is doing. Could you elaborate on why you think the result here is unexpected?

[maurice1408]

My error... I do apologise, thank you for the response sorry to take up your valuable time! Love duckdb