Slashdot Mirror
When Does Y2K Begin?
The popular perception of the "Y2K moment" is based on local time, with Y2K starting in the Pacific Ocean and gradually sweeping West, hour by hour, time zone by time zone. But is this correct? Most large, critical systems run on GMT. Air Traffic Control and most military systems certainly do. So is it possible that H-Hour for Y2K failures is GMT, not local midnight? Instead of local glitch after local glitch, are we more likely to see a single giant "galoomph" at GMT midnight, which is 7 p.m. US EST and 4 p.m. US PST - and 11 a.m. on January 1 in Sydney, Australia?
Thank you for your support.
There's a very good World-Wide countdown clock at Time and Date (they also have a non-java version). The year 2000 starts in the Christmas Islands less than seven hours from the time of this posting.
:-)
For those who are sticklers for detail, they also have a countdown to the new millenium
----
----
Open mind, insert foot.
Some of it was written not more than 1 year ago (yes: 1 year, I too needed to sit down when I ran into that baby). Some of it dates back to the AT&T UNIX days, is present in all major UNIX vendors' distributions, and yet still turned out to be buggy. Don't believe it? Ask (for instance) HP about the Y2K-1 bug in unpatched SCCS versions that hit on January 1, 1999 at 00:00:00 (while I was watching it, no less).
--
Linux user since early January 1992.
Sydney is on daylight saving now, so we're GMT +11 at the moment.
One of the TV channels (9) is running a 25 hour special watching the new year come in from all around the world. However, at 10am Saturday, they have:
Today on Saturday: Y2K special
Today On Saturday will update and report any major problems associated with the Y2K bug. In the event of nothing or little to report, Channel Nine will revert back to the Millennium live coverage.
I think that it will run for about ten to fifteen minutes, but I could be wrong. Anywhere else doing something "special" like this?
Y2K will begin on January 1, 1900!
Bruce Perens.
C, and hence languages derived from it like Perl, gets the year from a struct that really contains the year minus 1900. Therefore about half of the 2-digit year formats out there will be 3 digits next year.
Cheers,
Ben Tilly
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Then I went searching.
It looks like you are right. NT is good for a few centuries, VMS for a few tens of thousands of years...
Unix of (AFAICT) all flavors, 32-bit or 64-bit, dies in 2038. (Despite many uninformed comments the the contrary.)
*sigh*
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Just today we shipped some files with cashflow calculations that settle a few days from now - in Y2K - and they were rejected as "old files" because the file-name went from 99 to 00.
Most of Y2K is small stuff like that. Stuff you won't hear about, but which people have to stay on top of.
But - big but - there will be some bigger things. For instance a friend of mine who works in Troy, Michigan has an inte resting story about the traffic lights...
Cheers,
Ben
PS and OT: That discussion software is kind of impressive. They produce - completely dynamically - over a million pages/day with over 20K posts. Yet their pages are pretty much always *very* fast. Their secret? Smalltalk and the knowledge that threaded software is not a good problem for a relational database. Oh, and yes, they run on Linux.
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Y2K bug has already hit for some systems -- systems with a need for near-term future dates.
I think we'll see some stuff starting 12 hours before midnight GMT (4am PST) out in the pacific, and some stuff sweeping, hour by hour across the planet, with a spike at midnight GMT due to stuff all over the planet running on GMT and then further stuff happening on the hour as local midnight wanders past more locations...
We'll also see some issues that don't come up until Monday morning when people go to work... Maybe some stuff on March 1 for code that doesn't handle that leap year correctly...
Overall, though, it's likely to just be minor glitches -- rural and third world power outages, but no (or few) major metropolitan areas without power; small airports with problems, but the international airports will be fine... etc. (there's also the terrorists and script-kiddies to worry about, who'll do it whenever they feel like it, likely midnight local time.)
GMT? Surely you mean UTC?
GMT (Greenwich Mean Time) is inadequately defined by the erratic motion of the Earth whose rate fluctuates by a few thousandths of a second a day as it wobbles along its axis and around the sun. This leads to the undesirable side effect of having variable length seconds, since all days are defined to have 24 hours of 60 minutes with 60 seconds each, but the length of the day varies.
UTC (Universal Time Coordinated) was devised and became effective on 1972/01/01 to remedy exactly this problem. UTC normally runs at the rate of cesium-beam atomic clocks, and when the difference between UTC and GMT approaches one second, a leap second is introduced to maintain synchronization.
Hence, nobody really uses GMT.
-W
Virtually all calendric systems that have ever been devised number years from 1. Why? Because that's how ordinal numbers such as first, second and so forth work. The first year was simply called the first year under many systems.
The Ancient Chinese and/or Japanese had a system where years were counted from the time the current Emperor ascended the throne. Some territories in the British Commonwealth also used this system for such purposes as dating legislation. The Romans counted years from the founding of Rome. Jews, Christians and Muslims number years from the timing of major events related to their respective religions. All these systems numbered from one. A "zeroth year in the reign of the current Emperor" is obvious nonsense.
That's why the date on the first day of the new century is going to be 01/01/01 (not 01/01/00!). Using the DD/MM/YY format that I am used to here in Australia, I could read this date as the FIRST day of the FIRST month in the FIRST year of the current century.
It's worth noting here that the way days in the month are numbered - starting from one - is unchanged from the time of the ancient Romans, from whom we got most of our calendar, including the names of most of the months. (For example: Roman Gods: January = Janus, March = Mars; Roman Emperors: July = Julius, August = Augustus; Numbered months: September, October, November, December = seven to ten in Latin.) Things that have changed over about 2,000 years are the number of days assigned to each month and which month is the first month in the year. March used to be the first month of the year. That's why the Leap Day is added to the end of February - it was added to the end of the year - and why the ninth month is called September.
The other reason the ninth month is called September is because the Romans did not have a lot of imagination when naming things. If they couldn't think of a good name, they just gave it a number instead. They even named their children this way sometimes - that's where the name Quentin, meaning "Fifth son" or "Fifth child" came from.
We owe a lot of our calendar to the ancient Romans. Including numbering from one. The Romans did not have a concept of "zero" - it's one of those concepts that might be obvious to us today, but until someone actually thought of it, it never occured to anyone. They didn't need it. Romans concerned themselves with real things, such as trade goods, and an order for zero amphoras of olive oil from Greece wouldn't be considered - if you're going to order something, you always order at least one of it.
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Y2K isn't the major problem with C software. It's the year 2038. On about January 18, 2038, C's 32-bit time wraps around if the time is encoded as a signed long, and sizeof(long) is 32 bits.
This will affect many date-related calculations in C software. It's not confined to Unix, Linux or any other similar systems, as I have found such software problems in software running on DOS platforms during date compliance testing that included Y2K compliance.
Yes, it means we're all going to go through a situation similar to Y2K all over again leading up to 2038. Nowhere near as bad, of course, but if nothing is done about it, there will be an impact. (Especially if Linux takes over the world!)
An amusing note: 2038 is Unix's Y2K, with the dates starting from 1970. DOS counts dates from 1980, so there could potentially be a Y2K problem on DOS software in 2048 (= 2K).
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
You are such a stupid shit, everyone with my intellect knows the Millennium starts next year.
;-)
A millennium is defined to be one thousand years. It says nothing about which thousand years. The issue is that, if you start counting from the first day of January, year 1, AD, you will not reach 2000 years until 1 Jan 2001.
But, consider: All dates are arbitrary creations of mankind, and the turning point between 31 Dec 1 BC and 1 Jan 1 AD is particularly arbitrary.
So, define the "First Millennium AD" to begin 1 Jan 1 BC. Thus, 1 Jan 2000 will be the first day of the Third Millennium. Problem solved, and we can use dramatic words to describe the dramatic numbers.
Or, so I rationalize it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Oh, C software is very very vulnerable. Take a look at GNU software that has had problems.
Or a list of changes FreeBSD has made. (Note that about half of these are ported applications, not FreeBSD specific)
Or look here at some reasons why C is vulnerable to Y2k problems.
Just because it was written in C doesn't make it Y2k bugproof. Using time_t when possible is great, but the act of trying to make things human readable/parseable makes it harder.
Note too that most old Verisign keys expire on 12/31/99, people with old browsers should have fun on SSL sites. (Netscape allows 'Continue Anyway', IE won't allow you to)
Kevin
Sheesh this has been brought up time and again.
At the time the basis of the current calander was being "thought out", there was a monk (can't remember his name) who translated the roman system into a newer system, which is the basis of the Gregorian calander in use today. One of the reasons for this, was "Why should the church use a calander based on the rule of a Roman Emperor?" They finally decided on the year of christ's birth as the founding date. But they didn't use the current numbering system, they used roman numerals. How do you express 0 in roman numerals?
The romans had no concept of how to represent "nothing" so they took christ's birth as the year 1 AD. If you want to get really deep into this, you will also find that the date of christ's birth, the date of his death, and the actual number of years that had passed since his death to the time of the creation of the AD system was inaccurately calculated, due to misunderstandings of how lunar time, and siderial time interrelated, as well as simple "miscalculations".
However, even then, the calander was not 100% correct. Leap years were added, (to account for the drift caused by the fact that the rotation of the earth on it's axis, and the rotation of the earth around the sun do not mesh terribly well, there being approximately a 0.25 day difference) and then they were further resolved. The final rule (which is very accurate over large numbers of years) states that a leap year occurs..
On top of this, you have leap seconds, to bring our time in sync with universal constants (this is in relation to astronomical events). The earth is actually slowing down (very very slowly, DON'T PANIC!), plus the orbit of the earth is not circular, but is actually slightly wobbly.
The real problem, and the reason that causes all the trouble for systems designed by people that use 2 digit dates, is caused by the human ability to contract and shrink things, effectively encoding them in a method that while it appears logical to us humans, can cause all sorts of problems for computers. The human race has only itself to blame.
BTW: If you ever wondered why the calander is called the "Gregorian calander", it was named after the Pope at the time it was finally ratified (with leap years added), Pope Gregory.
Let's have some fun splitting these hairs in real tiny pieces.
There are several standards used for keeping track of time. The most important, by far, is Universal Time Coordinated (UTC), sometime known as GMT (Greenwhich Mean Time). This is the standard time for Earth, and it is with respect to this time that local time is defined (offset by a certain number of seconds, generally a multiple of 3600, i.e. an integer number of hours).
UTC does not flow linearly. That is, the interval between time t1 UTC and time t2 UTC is not always t2-t1. This is because leap seconds get inserted occasionally in UTC, so as to keep it more or less synchronized with the sun. More precisely: there are 86400 SI seconds in an SI day; but the mean solar day is approximately 2 milliseconds longer, because the Earth's rotational period is getting longer (the Earth is slowing down) at an order of magnitude of 1 millisecond per day per century. Terrestrial Time (sometime called Ephemeris Time) is the astronomical time: it is currently 0.184 seconds (roughly) fast of UTC. And UTC will be corrected so as to always keep it to within 0.9 seconds of TT (i.e. the sun should always be overhead on Greenwhich meridian to within 0.9 seconds at noon UTC).
Adding a leap second can take place after December 31 or June 31 (or possibly also March 31 or September 31, but that has never occurred), in the following form: after 23:59:59UTC comes 23:59:60UTC and after that comes 00:00:00UTC. The last leap second happened after December 31, 1998, and there will be no leap second after December 31, 1999 (today). It is the International Earth Rotation Service that is in charge of deciding when a leap second should be inserted. (Theoretically, a second can also be substracted, but that has never happened and presumably never will.)
The other important time standard is the Temps Atomique International (this is in French because the Bureau International des Poids et Mesures is in Sèvres, France), TAI for short. Contrary to UTC, TAI is a linear time scale (to the best of the precision we can achieve, that is, i.e. to within a few dozens of nanoseconds per year). TAI ticks one second every SI second, and it is maintained by averaging over about 50 atomic clocks around the world (there is no Master clock for TAI); the calculated offsets of the atomic clocks wrt TAI can be found in this FTP directory.
The Temps Atomique International and the Universal Time Coordinated are offset one to the other by an integer number of SI seconds (since 1972). This offset increases by one every time a leap second is inserted in UTC. Currently (since January 1, 1999 and at least to June 31, 2000) TAI is 32 seconds fast of UTC (so by the time UTC reaches January 1, 2000, 00:00:00, TAI will read January 1, 2000, 00:00:32).
So TAI will say Y2k precisely 32 seconds before UTC says so. (There is also GPS time, which is exactly 19 seconds back of TAI, but never mind that one. And, of course, there is Terrestrial Time, which nearly coincides with UTC, but not by a round number.)
Now, which of these times should be used on computers? Well, if you look in the /usr/share/zoneinfo/ directory of a GNU system, you will notice that there is a right/ subdirectory which contains nearly identical zone info files. The difference is this: the zone info files in the right/ directory account for leap seconds, whereas the ones outside this directory do not. Thus, if your /etc/localtime points to a right/ time zone, exactly 32 seconds will be substracted from your system clock before it is corrected by the time zone offset.
System time should be a linear time. If clocks were precise enough, it would be inadmissible to skew the clock by as much as one second (even by diluting the effect over a certain period). Thus, system time should be put to TAI (and not to UTC, let alone local time). This is why the right/ time zones are there: if you set your system clock to TAI and set your /etc/localtime to point to a right/ time zone, then your local time (as returned by the localtime() library function call) will be offset to UTC, as it should.
On the other hand, the POSIX standard (see POSIX.1, Annex B, 2.2.2) specifies that the time() system call should measure the difference between the current UTC time and the UTC time of the Epoch (January 1, 1970 at 00:00:00UTC). This is most unfortunate, because a difference of UTC times is not a number of seconds elapsed. And it is especially unfortunate since the rules for computing UTC from TAI were rather complicated before January 1, 1972 (at which time UTC was resynchronized to TAI-10s). Thus, the Unix Epoch, though it is January 1, 1970 at 00:00:00UTC, is actually January 1, 1970 at 00:00:08.000082TAI, and although on January 1, 2000 at 00:00:00UTC (January 1, 2000 at 00:00:32TAI) exactly 946684823.999918 seconds (as measured with respect to TAI) will have elapsed since the Unix Epoch, the time() function will return 946684800.
This being so, either the POSIX standard is mad, or the right/ timezones are wrong. I would tend to say that POSIX is crazy, and that system clocks should measure TAI and leave out the leap seconds. But since system clocks are synchronized by NTP, and since NTP gives UTC (while skewing the system clock to somehow jam in the leap seconds), the POSIX standard is followed de facto. (As a compromise, I would suggest moving the Epoch back in time by 82 microseconds to avoid these funky non-integer figures.)
If I recall correctly, VMS measures time using the Modified Julian Date. This is also synchronized with UTC. January 1, 2000 will be julian day 2451544.5, so MJD 51544.
To summarize, I say that Y2k is when the Unix time() function returns 946684800, which is exactly 946684823.999918 second of atomic time after the Unix Epoch.
Another stupid bit of trivia: according to ISO (the ISO8601:1988 standard), Y2k doesn't start until the first monday of the year, i.e. January 3, 2000. As for January 1, 2000, it is still ``day 6 of week 52 of 1999''. See your local emacs for information on what this day is in various other calendars.
Obviously the correct answer is local time. That's when all of the techie wannabes will be sitting at home watching their home system (Windows, natch) tick over to 00:00 01-01-;0 panting to see the first Y2K bug. (Of course, since they're wannabes they won't know that only problem they're likely to see at exactly midnight is in the RTC - both Windows and Linux only use the RTC to initialize a software clock during boot-up.)
Few people will notice that the power, TV, etc., fails to go off at midnight UTC. Even if there is a big "oomph," recent newspaper and TV reports make me doubt that the reporters will understand the situation well enough to explain it everyone else. The recent snafu with British credit card processing is a prime example. (CNN, I think, described the problem as being due to the clock being set ahead to 2000 for no discernable reason.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
According to this article in the Boston Globe, a Y2K-related failure happened yesterday when credit card swipe machines in the UK failed, because they tried to look ahead 4 days and when they "compared Dec. 28, 1999 with Jan 1, 2000, they failed to function because they read the date as Jan. 1, 1900". Oops.
Moral of the story? When do the problems actually start happening? They've started happening already. Hopefully most of them will be mostly minor problems, though? (Although if you were a merchant in the UK, what happened yesterday wasn't minor. Some of the merchants are screaming for blood, and are thinking about sueing the bank who made the terminals.)
Why don't we track actual Y2K events here on Slashdot as well as non-events? The relevant data would be the time it occurred, and where. But we should also track the things that continue working. Is the power still on? Did money come out of the ATM, and was the balance correct? And every single event posted will indicate someone who has a working computer and a functional network connection.
All of this information could serve as a good counterpoint to the Y2K hysteria. And speaking of that, I want to hear everyone's votes for the most hysterical Y2K disaster book. I think it deserves a review here around the Ides of March. We can stab the author in the back with a review that point out every false prophesy.
The net will not be what we demand, but what we make it. Build it well.