5 ms·

I have been working on COBOL systems for quite a while now. Currently and for most of my career, we mostly always use DB2 compatible dates ("CCYY-MM-DD"). Pre

I have been working on COBOL systems for quite a while now. Currently and for most of my career, we mostly always use DB2 compatible dates ("CCYY-MM-DD"). Pre-Y2k a lot of dates were created with: ACCEPT WS-DATE FROM DATE. The above WS-DATE was in YYMMDD format, which is why there was a Y2K issue and needed to be resolved with windowing code. However, windowing code wouldn't work for somebody that was over 100 years old... Doing a little research there is also (which I have never used since we just use DB2 and date parameter input files for CCYYMMDD dates): ACCEPT WS-CENTURY-DATE FROM CENTURY-DATE. This date is in CCYYMMDD format. According to google, the epoch for this date is January 1st, 1601.

Aloisius 2y ago
I'm not sure how a date in the format YYYYMMDD can have an epoch of 1601. Epochs are used when storing the offset in some unit like seconds or days to a reference date. The epoch for a year YYYY is 1* BCE (since there is no year 0). It doesn't make sense at all though for YYYYMMDD where there are multiple units and 0 is invalid for two of them. * You're not really supposed to use dates < 1582 in ISO 8601 though without prior agreement though it's meaning isn't really defined. 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.
- skissane 2y ago
  > 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.
- cwbriscoe 2y ago
  https://en.wikipedia.org/wiki/Epoch_(computing) https://en.wikipedia.org/wiki/Epoch_(computing) (CTRL-F 1601) Also notice, no mention of 1875. Also just search "CENTURY-DATE COBOL Epoch" If you search "CENTURY-DATE COBOL Epoch 1875", it is mostly just recent entries debunking 1875 as an epoch.
- HideousKojima 2y ago
  >I'm not sure how a date in the format YYYYMMDD can have an epoch of 1601. Remove the CMOS battery from a computer with no internet connection running Windows XP and it will default to the 1600's
bborud 2y ago
Using an epoch of jan 1 1601 is ... interesting since it means you would have to deal with the switch from julian to gregorian calendar in september 1752. This included dropping 11 days. Calendars and historic records is a pain.
- zosima 2y ago
  Different countries switched to the Gregorian calendar at different times. Pope Gregory XIII papal bull went into effect October 1582, see: https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar And so 15 October 1582 used to be the 0 for some COBOL date functions. Later that was changed to Jan 1 1600. In IBM's systems you can control what you prefer by a switch: https://www.ibm.com/docs/en/zos/2.4.0?topic=services-date-limits https://www.ibm.com/docs/en/zos/2.4.0?topic=services-date-li...
  - adbachman 2y ago
    No joke, I actually hit this condition in a test suite and ended up stumbling across the October 1582 date in a Ruby library. It wasn't until I searched "October 10 1582" on the Web that I learned the significance. https://gist.github.com/abachman/f97806e1c0fe8e4e1849e5f8412fd339#observations https://gist.github.com/abachman/f97806e1c0fe8e4e1849e5f8412... tl;dr - MySQL uses 1000-01-01 as the minimum value for a datetime field. Different Ruby libraries use different methods to represent dates, which can lead to situations that appear to claim that 1000-01-01 != 1000-01-01.
- twic 2y ago
  I assume they just use the Gregorian calendar throughout - roughly what is called "proleptic Gregorian" [1], although since the Gregorian calendar started on 15 October 1582, which is before 1601, it's not really proleptic. Just barely retroleptic. [1] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
apaprocki 2y ago
The Windows epoch is January 1st, 1601. The rationale is: "The Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed. In other words, it was chosen to make the math come out nicely."
- Maken 2y ago
  Still more logical than January 1st, 1970.
  - B1FF_PSUVM 2y ago
    Unix guys weren't overthinking it on systems running on 16 kB of RAM, or whatever. Just get a damn number, sheesh.

Aloisius 2y ago

I'm not sure how a date in the format YYYYMMDD can have an epoch of 1601. Epochs are used when storing the offset in some unit like seconds or days to a reference date. The epoch for a year YYYY is 1* BCE (since there is no year 0). It doesn't make sense at all though for YYYYMMDD where there are multiple units and 0 is invalid for two of them. * You're not really supposed to use dates < 1582 in ISO 8601 though without prior agreement though it's meaning isn't really defined. 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.

skissane 2y ago
> 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.
cwbriscoe 2y ago
https://en.wikipedia.org/wiki/Epoch_(computing) https://en.wikipedia.org/wiki/Epoch_(computing) (CTRL-F 1601) Also notice, no mention of 1875. Also just search "CENTURY-DATE COBOL Epoch" If you search "CENTURY-DATE COBOL Epoch 1875", it is mostly just recent entries debunking 1875 as an epoch.
HideousKojima 2y ago
>I'm not sure how a date in the format YYYYMMDD can have an epoch of 1601. Remove the CMOS battery from a computer with no internet connection running Windows XP and it will default to the 1600's

bborud 2y ago

Using an epoch of jan 1 1601 is ... interesting since it means you would have to deal with the switch from julian to gregorian calendar in september 1752. This included dropping 11 days. Calendars and historic records is a pain.

zosima 2y ago
Different countries switched to the Gregorian calendar at different times. Pope Gregory XIII papal bull went into effect October 1582, see: https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar And so 15 October 1582 used to be the 0 for some COBOL date functions. Later that was changed to Jan 1 1600. In IBM's systems you can control what you prefer by a switch: https://www.ibm.com/docs/en/zos/2.4.0?topic=services-date-limits https://www.ibm.com/docs/en/zos/2.4.0?topic=services-date-li...
- adbachman 2y ago
  No joke, I actually hit this condition in a test suite and ended up stumbling across the October 1582 date in a Ruby library. It wasn't until I searched "October 10 1582" on the Web that I learned the significance. https://gist.github.com/abachman/f97806e1c0fe8e4e1849e5f8412fd339#observations https://gist.github.com/abachman/f97806e1c0fe8e4e1849e5f8412... tl;dr - MySQL uses 1000-01-01 as the minimum value for a datetime field. Different Ruby libraries use different methods to represent dates, which can lead to situations that appear to claim that 1000-01-01 != 1000-01-01.
twic 2y ago
I assume they just use the Gregorian calendar throughout - roughly what is called "proleptic Gregorian" [1], although since the Gregorian calendar started on 15 October 1582, which is before 1601, it's not really proleptic. Just barely retroleptic. [1] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar

apaprocki 2y ago

The Windows epoch is January 1st, 1601. The rationale is: "The Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed. In other words, it was chosen to make the math come out nicely."

Maken 2y ago
Still more logical than January 1st, 1970.
- B1FF_PSUVM 2y ago
  Unix guys weren't overthinking it on systems running on 16 kB of RAM, or whatever. Just get a damn number, sheesh.