Mark, you're right on concerning the developer's way of doing things.
Coming from a Win32 program point of view, I can say that internally Windows
NT/95/98 use internal information that goes from 1981? to year 9999, but it
depends solely on the developer as to how they interpret, display and write
that information. The developer has free reign to display that information
in any format they choose and alot of it depends on what country they are
producing it for. If they write to a database in a mm/dd/yy format for
example and another program chooses to use that display info for input
without getting drilling down to the bits), things could get out of hand.
>You are correct in that most OS's store dates in the correct format
>"internally". This is where we run into problems. Unix, being a 32bit OS
>long standing, uses a 32bit clock library that basically increments from an
>arbitrary date set in the early 1970's. Unix doesn't actually know what
>and time is, only that so much time has elapsed since January 1, 1973 (or
>whatever), and the date is calculated accordingly. This 32bit library will
>into problems, I believe, in 2027 when it hits it's limit and rolls back
>to 0. At that point I hope we'll be using a higher bit clock library or
>OS rev's to alleviate the problem.
>DOS and it's derivitives, utilize a different starting date and smaller bit
>library so the rollover problem occurs earlier. Only OS patches and/or
>upgrades alleviate the problem fully.
>On the application side, in my Y2K research for my firm, we found that only
>programs which contravened correct programming practice may cause problems
>the Y2K boundary, given that your hardware and OS are Y2K compliant. An
>example of incorrect programming practice would be to query the Real-Time
>or BIOS clock directly to get date information and use an internal clock
>library, as opposed to querying the OS clock for date information. No
>applications that we checked did this kind of thing. Most get their clock
>from the OS. That's not to say that a user created script or database
>have been written incorrectly, but that in most cases, the OS, and the
>applications supplied with it, will function correctly.
>> Actually, DOS (and its derivatives) do, like Unix, store dates in Y2K
>> formats (there may be exceptions, but this is true for the most part).
>> The Y2K problem is mostly about old mainframe OS's and apps, but it also
>> affects the external interfaces of modern OS's - such as the COMMAND.COM
>> 'date' command. Remember, the line between system and app is a grey
>> one, and I wouldn't be at all surprised to find somewhere, in some
>> "system" database or config script, a 2 digit date assumption in Linux
>> or some other Unix system.
>> And then, of course, there is all the user written stuff for Unix and