Millennium bug. Part deux.

Nothing I worked with didn't have floating point. Except the Elliott 803B, the EMR 6130, and smaller DEC machines.

Even such as the Sigma 7 had 64-bit floats (known as "double-precision"). The big CDC machines (admittedly more scientific than commercial), *only* had floating point - no integer hardware. But as they were 60-bit machines with a

COBOL I never used.

EXcept that UNIX (and UNIX like systems such as Linux) moved to 64 bit dates a while ago.

Why seconds? Or days? Why not microseconds? That was what I was very used to. More on the system side than applications, to be sure.

I guess it was a reasonably compact way of storing a date and time to sufficient accuracy for timestamps. Microseconds would have needed more storage space (or a span less than 68 years), whole days only (not sure what michael adams was getting at as I have him killfiled) are not enough.

This is to give an illustration of time keeping on a computer.

"Date range

(File times are 64-bit numbers counting 100-nanosecond intervals (ten million per second) since 1601, which is 58,000+ years)"

Since some programs store information about files, in formats like that (units of 100-nanosecond), I had to write myself a little program to convert the machine representation, back into a useful date.

For example, "everything.exe" search tool, stores datestamps in its index file and they're in machine representation and not meaningful to humans. There is no apparent attempt to make them "efficient" either, as the file contains decimal numbers, comma separated.

And one of the Microsoft library routines, handles the 64-bit number as a "high" and "low". This is a comment and example from a source file.

/* typedef struct _FILETIME { = 131679807063691748; DWORD dwLowDateTime; 1D3D216 0x3C1F91E4 DWORD dwHighDateTime;

timein.dwLowDateTime = 0x3C1F91E4; timein.dwHighDateTime = 0x01D3D216; */

If I run the conversion utility, I get...

H:\> filetime.exe 131679807063691748

With no particular attention to time zone or anything. It's just so I can compare the value stored in a file in the machine form, versus what File Explorer shows for it.

The purpose of printing the hexidecimal, is to show how many more bits are available to store later dates.

Paul

The system used a double word - 64 bits. Still less than most ways of stori ng anything even vaguely like YYMMDDhhmmss. Some processors only updated th e actual clock every two microseconds.

Made it very easy to calculate differences - compared with most other possi bilities. Most particularly if you have no idea when coding whether the dif ference is likely to be microseconds or years avoiding the artificial disti nction between calendar and clock is nice and simple. Differences of calend ar dates and conventional time formats is just so tedious (even if in pract ice there is a simple function that will do it, the behind-the-scenes proce ssing is much greater).

Because microseconds are irrelevant when calculating things like bank interest.

Possibly had someone at some point had the starting insight that microseconds, seconds even minutes or hours are totally irrelevant in 99% of commercial applications outside of telephony, then instead of allocating resources to calculating and storing microseconds, seconds minutes and hours they might have considered allocating resources to a four digit year instead, and Y2K need never have happened.

michael adams

...

ld be different.

onds, seconds

tions outside

If you stored microseconds in an unsigned 64-bit binary field, then Y2K wou ld not have happened.

And recording when things happened is all too important in many commercial contexts. Sure, not likely necessary for calculating interest, but it can m ake life so easy to use just one format for all purposes. But nor are secon ds relevant for such interest calculations.

Day number is a reasonable alternative to microseconds where only date is r elevant - but the difference is one simple integer division and a small amo unt of storage.

But surely the point is that when thse programs were written they didn't have 64 bits to play with ?

Even your "one format" uses two different "epochs"; the year 1900 for microsoft and others, the year 1974 for Unix based applications, or at least so I believe

Indeed. With unsigned 16 bit integers using day numbers you could have an epoch starting in

But instead it was decided to also store hours, minutes, seconds, in many cases - as in so ,may other instances too numerous to mention, for no other reason than *but just because they could!

michael adams

...

In my case I'm starting with the Date: field in an email, which has a well-defined format - and it has time and timezone fields. Easy enough, then, to obtain seconds since the epoch.

Storing as seconds is precise enough for this usage and separates data storage and manipulation from pesentation to the user.

n the interim,

econds, seconds

cations outside

would not have

have 64 bits to

ial contexts.

to use just one

epoch starting

y cases - as in

ut just because

When these programs were written thy must have had the space otherwise they could not have been implemented. We are talking 1970s onwards (not sure qu ite when in the 1970s - possibly towards the end). The architecture actuall y transferred data to the processor in double words.

Epochs, as you describe, only matter when transferring information between regimes which use different references.

Worse, by far, in terms of storage, was using character representation. E.g . YYYY using four bytes. Just a date requires two words (64 bits). With micro seconds, you can store a date AND a precise time in the same number of bits . And simplified arithmetic operations come as a bonus.

Binary Coded Decimal was also pretty unsatisfactory.

perhaps they did

but no-one was daft enough to make 0-20 2001-2020 whilst leaving 21 as 1921, Computers weren't invented then.

anybody with any sense used 80 as the cut off point for the 2000s

HTH

tim

in an effort to

??, which would

The "computers weren't invented then" assumption was shown to be severely p roblematical when the DHSS needed to take on people born in the nineteenth century. (Probably many other areas as well. I just know a little about tha t example.)

Well known to some of us.

Especially those who worked on the original millennium bug _without_ putting in any hacks...

There's actually a justification for it. The cost of storing all those

My two favourite ones were the supermarket that nearly threw out all its corned beef around 1990. It had ten year sell-by dates.

And the insurance for my wife's car. They excluded the bug. It had a carburettor and points. It didn't know the date, never mind had any bugs for it.

Andy

Caused entirely by the fact that storage was REALLY expensive so no-one who valued his job stored dates in DDYYCCYY format when DDYYMM or MMYYDD was perfectly adequate. It's the way it was done, just like no-one thought there was anything wrong with the Black and White Minstrel show on BBC1 at that time.

So that means LOTS of problems storing dates of birth for the older generation. There are 14,500 people over 100 in the UK.

Clearly you were never involved with the design and development of COBOL-based computer systems in the 60's,70's and 80's when storage was really expensive. Storing a date with the century was simply pointless to most applications. It was the ones that used the date as part of a composite index key like YYMMDD********* that would have failed on 01/01/2000.