Skip to main content
Retrocomputing

Return to Answer

improved formatting
Source Link
Martin Maly
Martin Maly
  • 5.6k
  • 19
  • 45

Y2K issue was principially caused by the need to save disk space/storage in relation to dates - as mentioned already storing a date of DD/MM/YY requires less space that that of a date of DD/MM/YYYY - i.e. you would be saving a two bytes for every date on every record - as mentioned when disc space was limited/expensive this was the norm. Prior

Prior to Y2K activity (late 90s) I had to work on a 1980 date issue -, because our systems that were in use would remove the decade part of the year and then pack the date i.e. the date was stored as DDMMY - when. When this was saved as packed decimal this would then only require three bytes of storage - when. When ever dates needed to be printed then date was reformatted and a constant of a 7 added for the decade (i.e. date saved as S31057 - printed as 310577)- mid.

Mid 1979 we started getting statement due dates appearing with a year of 1970 instead of 1980 due to the above -, which needed remediating on the same basis as some Y2K fixes i.e. checking single part of the year date to be greater than five force a 7 if less than or equal to 5 force a 8 - this. This ensures a couple of years extra use - glad. Glad to say I left company before 1985 so don'ydon't know what naterialisedmaterialised then. 

Since that time I have met older developers who say they has same issue with dated oving from the 1960s to 1970s -, although I guess not as many.

Y2K issue was principially caused by the need to save disk space/storage in relation to dates - as mentioned already storing a date of DD/MM/YY requires less space that that of a date of DD/MM/YYYY - i.e. you would be saving a two bytes for every date on every record - as mentioned when disc space was limited/expensive this was the norm. Prior to Y2K activity (late 90s) I had to work on a 1980 date issue - our systems that were in use would remove the decade part of the year and then pack the date i.e. the date was stored as DDMMY - when this was saved as packed decimal this would then only require three bytes of storage - when ever dates needed to be printed then date was reformatted and a constant of a 7 added for the decade (i.e. date saved as S31057 - printed as 310577)- mid 1979 we started getting statement due dates appearing with a year of 1970 instead of 1980 due to the above - which needed remediating on the same basis as some Y2K fixes i.e. checking single part of the year date to be greater than five force a 7 if less than or equal to 5 force a 8 - this ensures a couple of years extra use - glad to say I left company before 1985 so don'y know what naterialised then. Since that time I have met older developers who say they has same issue with dated oving from the 1960s to 1970s - although I guess not as many.

Y2K issue was principially caused by the need to save disk space/storage in relation to dates - as mentioned already storing a date of DD/MM/YY requires less space that that of a date of DD/MM/YYYY - i.e. you would be saving a two bytes for every date on every record - as mentioned when disc space was limited/expensive this was the norm.

Prior to Y2K activity (late 90s) I had to work on a 1980 date issue, because our systems that were in use would remove the decade part of the year and then pack the date i.e. the date was stored as DDMMY. When this was saved as packed decimal this would then only require three bytes of storage. When ever dates needed to be printed then date was reformatted and a constant of a 7 added for the decade (i.e. date saved as S31057 - printed as 310577).

Mid 1979 we started getting statement due dates appearing with a year of 1970 instead of 1980 due to the above, which needed remediating on the same basis as some Y2K fixes i.e. checking single part of the year date to be greater than five force a 7 if less than or equal to 5 force a 8. This ensures a couple of years extra use. Glad to say I left company before 1985 so don't know what materialised then. 

Since that time I have met older developers who say they has same issue with dated oving from the 1960s to 1970s, although I guess not as many.

Source Link
oldfella
oldfella
  • 21
  • 1

Y2K issue was principially caused by the need to save disk space/storage in relation to dates - as mentioned already storing a date of DD/MM/YY requires less space that that of a date of DD/MM/YYYY - i.e. you would be saving a two bytes for every date on every record - as mentioned when disc space was limited/expensive this was the norm. Prior to Y2K activity (late 90s) I had to work on a 1980 date issue - our systems that were in use would remove the decade part of the year and then pack the date i.e. the date was stored as DDMMY - when this was saved as packed decimal this would then only require three bytes of storage - when ever dates needed to be printed then date was reformatted and a constant of a 7 added for the decade (i.e. date saved as S31057 - printed as 310577)- mid 1979 we started getting statement due dates appearing with a year of 1970 instead of 1980 due to the above - which needed remediating on the same basis as some Y2K fixes i.e. checking single part of the year date to be greater than five force a 7 if less than or equal to 5 force a 8 - this ensures a couple of years extra use - glad to say I left company before 1985 so don'y know what naterialised then. Since that time I have met older developers who say they has same issue with dated oving from the 1960s to 1970s - although I guess not as many.