3 ms·

> I'm not sure how a date in the format YYYYMMDD can have an epoch of 1601. IBM mainframe Cobol contains builtin functions which convert between YYYYMMDD strin

> I'm not sure how a date in the format YYYYMMDD can have an epoch of 1601. IBM mainframe Cobol contains builtin functions which convert between YYYYMMDD strings and integers - and 1601 is the epoch they use for that integer representation. I assume the person you were replying to was talking about this fact, just stating it somewhat confusingly > The epoch for a year YYYY is 1* BCE (since there is no year 0). Well, there is a year 0 in astronomical year numbering. One can say that 0 CE = 1 BCE and -1 CE = 2 BCE and more generally n BCE = -(n-1) CE for all integers n > 0. Maybe “0 CE” is incorrect per a strict definition of “CE”, but it is correct if we define it less strictly > * You're not really supposed to use dates < 1582 in ISO 8601 though without prior agreement though it's meaning isn't really defined. There’s really only two choices: proleptic Gregorian, or Julian. I don’t know why ISO 8601 doesn’t just mandate proleptic Gregorian with astronomical year numbering. But I suppose in the rare cases a computer system needs to represent pre-1582 dates (such as historiography), Julian is the norm. I suppose they could extend the syntax to specify which calendar is being used > Edit: There do exist standards that default to 1875-05-20 when there's a null date however (GIS-related), but I've not seen anything that suggests the SSA uses it. Do you know which ones specifically? Would be interested to know this

Aloisius 2y ago
The COBOL days since 1601 epoch makes sense. Now that I think about it, if those functions don't work with negative numbers, then I imagine even the YYYY strings couldn't have years before 1601. > Do you know which ones specifically? Would be interested to know this This is the only one I've found: https://docs.ogc.org/is/18-010r7/18-010r7.html#100 https://docs.ogc.org/is/18-010r7/18-010r7.html#100 Temporal datum with Calendar ... and with TimeOrigin omitted so should be assumed to be 1875-05-20.
- skissane 2y ago
  > The COBOL days since 1601 epoch makes sense. Now that I think about it, if those functions don't work with negative numbers, then I imagine even the YYYY strings couldn't have years before 1601. IBM mainframe COBOL has two operation modes, ANSI (where day 1 is 1601-01-01) and “Lilian” (where day 1 is 1582-10-14, the day on which the Gregorian calendar was first introduced). ANSI mode complies with ANSI/ISO standards for COBOL, Lilian is an IBM-only legacy standard. So, in Lilian mode, the earliest value for YYYY is 1582. I don’t believe negative numbers are accepted.

Aloisius 2y ago

The COBOL days since 1601 epoch makes sense. Now that I think about it, if those functions don't work with negative numbers, then I imagine even the YYYY strings couldn't have years before 1601. > Do you know which ones specifically? Would be interested to know this This is the only one I've found: https://docs.ogc.org/is/18-010r7/18-010r7.html#100 https://docs.ogc.org/is/18-010r7/18-010r7.html#100 Temporal datum with Calendar ... and with TimeOrigin omitted so should be assumed to be 1875-05-20.

skissane 2y ago
> The COBOL days since 1601 epoch makes sense. Now that I think about it, if those functions don't work with negative numbers, then I imagine even the YYYY strings couldn't have years before 1601. IBM mainframe COBOL has two operation modes, ANSI (where day 1 is 1601-01-01) and “Lilian” (where day 1 is 1582-10-14, the day on which the Gregorian calendar was first introduced). ANSI mode complies with ANSI/ISO standards for COBOL, Lilian is an IBM-only legacy standard. So, in Lilian mode, the earliest value for YYYY is 1582. I don’t believe negative numbers are accepted.