3 ms·
Unless of course, you are trying to store the maturity date of a thirty year bond or mortgage.
by stevewilhelm 10y ago
Unless of course, you are trying to store the maturity date of a thirty year bond or mortgage.
- raverbashing 10y agoYou store the ISO date, you don't need a UNIX epoch to calculate that
- jdub 10y agoYou "store" it that way (as a string? no), but how are the relevant systems (database, OS, application) handling calculations with it?
- camiller 10y agothat many years ago it was probably stored on tape and processed on a mainframe by a COBOL program. No database, it was probably stored as a string, and the application would likely have been fix to handle it before it was a problem.
- acdha 10y agoThat COBOL program almost certainly _is_ a database – not a SQL database but the COBOL language standard specifies structured records and allows you to specify whether a file is sequential or indexed (see e.g. https://en.wikipedia.org/wiki/COBOL#Data_division https://en.wikipedia.org/wiki/COBOL#Data_division). In the case of Y2K, the problem was often that people defined a date filed as three values all declared as PIC 99 (i.e. a two-digit number). If they migrated to 4 digits, we're fine until Y10K. If they added a window (values less n are 19xx, etc.) or switched to Unix timestamps or a SQL database – there are products which let a COBOL runtime transparently map the indexed file semantics to SQL statements – then it requires more information to say whether it's at risk.
- wolfgang42 10y agoI work with a COBOL database, and interestingly all of the dates are declared as four PIC 99 fields, like this: 02 ITM-LAST-CHG-DATE. 03 ITM-LC-DATE-CC PIC 99. 03 ITM-LC-DATE-YY PIC 99. 03 ITM-LC-DATE-MM PIC 99. 03 ITM-LC-DATE-DD PIC 99. I assume this split between 'CC' and 'YY' is a relic of the Y2K updates, so they could add in a whole new field with a default of '19'.
- raverbashing 10y agomysql> SELECT TIMESTAMPDIFF(YEAR,CURDATE(), "2050-01-01"); +---------------------------------------------+ | TIMESTAMPDIFF(YEAR,CURDATE(), "2050-01-01") | +---------------------------------------------+ | 33 | +---------------------------------------------+ Seems to work fine
- jdub 10y agoThat's just the database, and one that we happen to know works.
- raverbashing 10y agoThe original comment referred to exactly this database, so it is relevant
- ams6110 10y agoYou should never store or work with dates as unix epoch-based timestamps. Use proper date/time datatypes, and manipulate them with library functions. Naive integer arithmetic on unix timestamps will bite you in the ass a hundred different ways.
- tyingq 10y agoCertainly a good idea, but sometimes it's difficult to tell if OS functions and 3rd party libraries you depend on are doing that. The ext4 filesystem in Linux, for example, uses epoch time. I think they have it all fixed now, but there were bugs still out there as recently as this year: https://bugzilla.kernel.org/show_bug.cgi?id=23732 https://bugzilla.kernel.org/show_bug.cgi?id=23732
- jdub 10y ago> Use proper date/time datatypes, and manipulate them with library functions. The point is: What do they do? There are plenty that will use... Unix timestamps (or worse). Or use those as the lowest common denominator for interchange. There are more systems at play than the data layer, and all of them will take every opportunity to bite you in the arse.