When Does Y2K Begin? 495
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?
galoomph (Score:1)
I run the NOC for a major american bank and I think that tomorrow night, right as I pull the power at midnight, just for grins, Im going to broadcast a giant galoomph over the NOC loudspeakers.
Thanks Hemos
Re:FLAMEBAIT HERE PLEASE (Score:1)
Re:FLAMEBAIT HERE PLEASE (Score:1)
Re:Answer: both and more. (and not much) (Score:1)
So you're a year old when you're born? (Score:1)
Allow me to be the first to.. (Score:2)
So who cares? Whether it starts NOW, at midnight localtime [12:30 in Newfoundland (;] or at 00:00 UTC, it doesn't mean fsck all. If it happens, it happens. And all I've seen point to it not really happening.
And for a smile, see the newest UFIE here [userfriendly.org] as they poke fun of the Y2K paranoid.
FLAMEBAIT HERE PLEASE (Score:4)
Thank you for your support.
Re:When Y2K will happen (Score:2)
----
When Y2K will happen (Score:4)
For those who are sticklers for detail, they also have a countdown to the new millenium [timeanddate.com]
----
Yes it Does matter GODDAMNIT! (Score:1)
I guess I should probably just find a house of ill repute cause it'll take me quite a while in Fort Myers.
Re:Look at the submission date on this article (Score:2)
But since "Komedy" sounds like part of K-Office or something else that's going to be included in KDE-2, and this thread is about Y2K, not KDE, I hereby declare your post off-topic.
Unless, of course, the KDE crowd secretly plans to release something called Y2KDE Saturday, in which case your post is the only one here that is ON-topic, and I owe you a most abject apology. ;-)
- Robin
Re:The problem will be people, not computers (Score:1)
My answer: WHO THE HELL CARES?!!! (Score:1)
Can we *PLEASE* consider refraining from being totally Y2K smitten for the next 72 hours?
Shit. What happened to the "Y2K Pledge" that someone (Hemos?) posted a while back.
I am *so* sick of Y2K.
Re:It simply doesn't (!) (Score:2)
The other one I mentioned also was "fatal": it was (is, actually, because to my knowledge it has not yet been fixed) a project database that would say "internal database error" when one tried to enter a project with an end date in 2000.
--
Re:It simply doesn't (!) (Score:2)
--
Re:It simply doesn't (!) (Score:4)
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).
--
interesting notes (Score:1)
Re:Why wasn't there any year 0? (Score:1)
----------------
Re:Data or Information? (Score:2)
--
Yep... (Score:1)
Well, it's just ticked over... (Score:1)
(Yes, I have probably had the singularly dullest New Year's Eve 1999 of any living person between 5 and 50 who observes the Christian calendar)
a pin ewe ear to you all!
Re:Teacher has a rotten apple (Score:1)
This is true, I swear I am not making this up. And I've yet to hear a clueless luser story that tops it
Re:It simply doesn't (!) (Score:1)
And I, like the pathetic slave I am, have to be in on Saturday just to post a "We're OK, the sky failed to fall" message to the web site.
Re:Slackware 7.0 as well (Score:1)
Last minute Y2K updates (Score:2)
Anyone else see any last minute updates?
Re:11am? (Score:4)
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 [sofcom.com.au]:
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?
12:00 midnight supposedly (Score:1)
NADA - Nothing! No Y2K problems *at all*! (Score:1)
You can pat yourselves on the back and take those enormous paycheques home now..
Re:My answer: WHO THE HELL CARES?!!! (Score:1)
-tor
Look at the submission date on this article (Score:2)
That's Komedy.
It simply doesn't (!) (Score:1)
Sure there must have been problems in the banking/insurance/financial sector with the old Cobol code, but computers hasn't used the decimal numbers for keeping track of time since sometime in the late sixties. Y2K is an application-software-only problem, and it occurs mainly with either _very_ poorly written software or with software written in a language/environment that has the problem (Cobol).
All modern software (from early '70s and newer) uses other ways to keep track on the time (eg. seconds from 1.jan 1970), it's almost entirely written in C, and it will not have a problem. (Even software written in other languages have the language compilers/environments written in C, and therefore doesn't have the problem either).
So why were there BIOS updates out ? Well if enough customers believe there is a problem, the manufacturers better do _something_ (eg. flip a few bits, insert a nop here and there) to give the customer the impression that a problem present was fixed. Marketing and crowd-of-lemmings stuff.
I would be willing to bet a beer with anyone on this. However, there is the _slight_ chance * consequence equation that makes me sort of reluctant to bet with all of slashdot, despite the incredible amount of beer I would receive. (This is a small country, I wonder if it would sink in the ocean once I won
My 1996-BIOS dual PPro keeps on running with it's vintage BIOS until it gets replaced in a few years, or until the apocalypse caused by the aforementioned crows of lemmings makes computers a little concern.
Happy new year !
(Oh, and if anyone has stocked up a few too many of those cal. 50 with IR scope and they figure they won't need them for looting/rioting/protection/whateverthehellyouthou
Re:It simply doesn't (!) (Score:2)
But the bug you see is only in formatting of output right ? The systems still work, the little clock in the top right corner just prints the wrong year, or ?
My argument is, that since most systems don't use decimal numbers internally, they will keep on running. Perhaps the user gets confused when he/she sees the wrong year (especially after a tough new-year's eve you can sort of get in doubt as to what century you're waking up in), but it's only formatting and not critical (outside the financial sectors).
Or have you actually seen a Y2K bug that caused something to *break* except for formatting/prettyprinting ?
Re:It simply doesn't (!) (Score:2)
The report can be re-printed when the problem is fixed. But if the only problem really turns out to be exactly this, formatting of output intended for humans-only, then the problem is small. I know pretty darn well that a syslog entry from 1985 doesn't belong in a recently installed PII system, and my supervisor at university will also have a pretty good understanding of whether the report I hand in is written in jan. 2000 or jan. 1900.
I have already seen some ``Y2K problems'', which were caused by people trying to upgrade BIOS software on systems to ensure Y2K compatibility. And I'm pretty confident that that will be all of the Y2K bugs I get to see. Even at the university some machines (especially a web-server holding lecture material that I desparately need now) are shut down due to Y2K. I nearly pissed my pants when I found out. Sure, there are lots of Y2K problems out there, but I have yet to see one which is caused by a problem in handling dates.
Okay. :-) (Score:1)
Welcome to Millennium#2, the Third Millennium. (Score:1)
A "zeroth year in the reign of the current Emperor" is obvious nonsense.
I could never understand this argument. How could anybody claim to have an intuative understanding of something which was decided upon two thousand years ago?
Is this 1999, or the one thousand, nine hundred and ninty-ninth year?
From my limited resources, the current calendar is set upon the birth of Christ. This was calculated in approximately 70AD by counting backwards on the Roman calendar. This and the calculation was later found to be incorrect, neglecting the reign of a particular emperor thus pushing the birth of Christ back to around 4BC.
Regardless, to counter a frankly silly argument that it is "obvious" that there was no zero; was Jesus, an infant like any other, ever zero years old?
Yes!, but nobody in the modern world would call him "Zero years old", they might say it is his first year of life, but most would say he is "minutes old", or "months old" or whatever.
Who's to know what was being thought of 70AD as to when or if there was a zero. Nobody I know of has stepped forward and claimed to have documentation to say that that monk fellow intended the birth of Christ to fall on zero or one. Though I'm sure somebody does have this information. I don't care enough to find out. Saying the new millenium starts in 2001 is saying that Jesus was one year old in year two and that by all modern numbering conventions, this is the one thousand nine hundred and ninty-ninth year, or... year number 1998.
Right or wrong, I don't really care all that much, but it is not "obvious" nor is it "nonsense." Pointless perhaps... but not nonsense.
Com'on, everybody knows this! (Score:5)
milk y2k for all it's worth.. :P (Score:2)
Factoring GMT into the equation just gives me an extra moment to watch for this nothing to happen.
I'm on call for the whole thing - I won't be paged, it'll be a cruisy night.
I'm just concerned with stocking up on alcohol and pre-booking my stomach pumping.
Re:Look at the submission date on this article (Score:2)
Oh, and while i'm at it the new millenium begins 2001! That's not stopping me from wearing my "Fuck the Millenium" [netizen.com.au] tshirt tonight though... and i get to recycle it next year!
Re:My answer: WHO THE HELL CARES?!!! (Score:2)
Why wasn't there any year 0? (Score:2)
Now, you may ask, did people in year 10 knew they were in year 10? No, they did'nt! So the
But wait, did people in 863 knew they were in 863? Damn it, probably not, either!
Fuck, that's really much more complicated than I thought!
All I wanna know (Score:2)
Chas - The one, the only.
THANK GOD!!!
Offtopic: Something That Would Be Cool... (Score:2)
As the ball drops in New York's Times Square, as millions of people count down the last seconds, the instant all the digits flip over to 2000...
...A big sign lights up, reading EXTRA BALL!
Schwab
Yup 19K and 100 vs 00 (Score:2)
Cheers,
Ben
Does this count? (Score:2)
Well a good chunk of the KDE crowd is in Germany, and Germany's abbreviation is DE, so the time that midnight arrives for them is by definition Y2K DE.
I think you owe an apology.
Cheers,
Ben
long is 32 bits on 64 bit machines (Score:2)
Why?
Because there is too much code out there that does stupid things like walks an array or malloc()ing data knowing that a long is 4 bytes, or talks over a network, sending longs out in protocols that have to interoperate with 32-bit machines.
The resulting porting nightmare is so bad that effort is taken to protect the average program from knowing that you are in a 64-bit environment.
Cheers,
Ben
There are 3 digit date formats next year! (Score:3)
Cheers,
Ben Tilly
I thought I was certain (Score:4)
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
It already has (Score:5)
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 [ezboard.com] 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.
Yes, mortgage software, credit cards (Score:2)
--
Re:Y2K-48 (Score:2)
Wrong. 2^10==8.
I had to go check. Because I realize I can make mistakes like that. You had me worried.
$ perl -e 'print 2^10';
8
Re:Y2K-48 (Score:2)
In context, you should have understood I
meant "to the power."
You are a troll for attempting to make me look
like more of a moron than I am. I kiss you.
Re:It simply doesn't (!) (Score:2)
I have had to fix systems that would have caused,
i.e., transaction reports to not be imported because of date calculations. A small problem?
The labor required to fix reports that would have been rejected would have been rather expensive considering that the problem would persist and compound until the software was fixed. So fixing the software was quick and simple. The consequences of not fixing the software might have been rather expensive.
Answer: both and more. (and not much) (Score:5)
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.)
Re:FLAMEBAIT HERE PLEASE (Score:2)
On another note, the calendar we currently use was calculated for some ancient monk's estimate of the birth of Jesus, starting at Year 0. That's right, despite all the pompous dorks proclaiming otherwise, the first millennium started at 0. Just like all real programmers would expect. Which makes Jan 1 2000 the first day of the third millennium.
"Moderation is good, in theory."
-Larry Wall
Re:Answer: both and more. (and not much) (Score:2)
Because programmers are interested in details/trivia and they are human.
I wish I had a dollar for every incorrect description of the leap year rules that has been posted on the Internet.
Leap year bugs are distressingly common in computer software.
DEC wrote an amusing SPR response [concordia.ca] on the subject.
GMT is Obsolete (Score:2)
The frogs^H^H^H^H^HInternational Earth Rotation Service (IERS) controls UTC.
Re:Seems to me it's already started! (Score:2)
Re:It's all alot of hype. (Score:2)
If I was going to rob a bank, this would be the time to do it. Assuming that the police would be tied up with other problems.
Re:It simply doesn't (!) (Score:2)
Re:I thought I was certain (Score:2)
Dave Barry... (Score:2)
Off topic I know, but I thought it was particularly amusing.
-pedantic (Score:3)
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
Re:-pedantic (Score:3)
I don't know where you French get off with this UTC time, but over here we all know that GMT is the only real time. :-)
Re:Why wasn't there any year 0? (Score:3)
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.
More C problems (Score:3)
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).
Re:Oh yeah! (Score:2)
My solution (Score:3)
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.
Re:It simply doesn't (!) (Score:5)
Oh, C software is very very vulnerable. Take a look at GNU software [gnu.org] that has had problems.
Or a list of changes FreeBSD [freebsd.org] has made. (Note that about half of these are ported applications, not FreeBSD specific)
Or look here [phys.rug.nl] 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
Re:Why wasn't there any year 0? (Score:5)
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.
Hair-splitting to smithereens (Score:3)
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 [obspm.fr] 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 [www.bipm.fr] 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 [62.161.69.5].
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.
It's already hit Microsoft (Score:2)
Y2K Starts Here in NZ (Score:2)
Teacher has a rotten apple (Score:2)
"kilo-" means "multiply by 1000" *only*. This isn't just a convention, IIRC it's the legal definition in essentially all nations under their respective "standards and measures" law. (This is how the US gets NIST and ANSI, Germany gets DIN, etc., and they all get together for ISO)
The use of "kilo-" to indicate multiplication by 1024 is a corruption of the term. It is currently tolerated in areas which are unambiguously computer related (e.g., before "byte" or "baud"), but it is legally risky and is most emphatically *not* correct before existing units such as "year". Or did you think that hard disks are sold in units of million-fold "mega-" and billion-fold "giga-" simply for the slightly inflated values?
To avoid the confusion caused by your former students attempting to refine legally defined terms there's been some discussion of introducing several new prefixes to indicate powers of two, but there's some resistance. IIRC, the abbreviations will be similar to the existing abbreviations but include a "b", e.g.,
kbb - kibobits - 1024 bits
kbB - kibobytes
Mbb - (meba?)bits - 2^20 bits
MbB
GbB - (giba?)
TbB - (teba?)
and so forth.
I thought that this proposal was an overreaction, but after seeing several people insisting that "kilo-" always refers to 1024-fold multiplication I have changed my mind.
(rant off)
That said, I agree that interpreting "Y2K" as 2048 AD is good for a quick laugh, but *only* for a laugh. It has absolutely no place on a "computer architecture final" other than a forepage intended to break the tension.
Windows systems use local times (Score:4)
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.)
Re:FLAMEBAIT HERE PLEASE (Score:2)
www.douglasadams.com/dna/pedants.html [douglasadams.com]
It's funny. Read it.
Unfortunately, I can't resolve the domain right now for some reason. Hope you have better luck.
Re: (Score:2)
Re:What Power and Phone Companies Fear (Score:2)
Y2K Timezones (Score:2)
Re:Dave Barry... (Score:2)
Or when you step out of a HomeStyle Buffet or Ponderosa and leave footprints in the asphalt.
Jazilla.org - the Java Mozilla [sourceforge.net]
Re:What Power and Phone Companies Fear (Score:2)
that and the grid will go down and then they'll panic over it. Same way with the power as you mentioned. I just plan to only have my computer (cable modem, so no phone lines to worry about) and TV on (other than normal stuff like VCR's)."
Picking up your phone (normal, not cell, i assume), shouldn't really do anything at all. The dial tone should be coming from the pbx. In fact, you should be able to call locally, no problam, because everybody is hooked into a local pbx. It's the long distance that might have trouble.
NYSEG (New York State Electricity and Gas, I believe) basically suggests that you just power down your computer. Everything else you can leave on. I'm sure what they
Jazilla.org - the Java Mozilla [sourceforge.net]
Re:FLAMEBAIT HERE PLEASE (Score:2)
--GnrcMan--
Re:Yup 19K and 100 vs 00 (Score:2)
Re:Y2K-48 (Score:2)
Y19K errors (Score:4)
It started *yesterday* (Score:3)
According to this article [boston.com] 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.)
Re:FLAMEBAIT HERE PLEASE (Score:3)
--
Breaking News! (Score:2)
And after all, if the Russians can't be trusted to fix their nuclear missile launch systems for Y2K, why do we think they would waste their time on a non-critical system like Yeltsin? And for him to malfunction like this, with just...lemmee see...42 minutes to go before the next millennium hits er, the uninhabited Pacific island of Karibata??
Coincidence???
Eh????
On a somewhat related note (failed early cyborg prototypes?), Larry King is about to kick off CNN's 100 hour coverage of the new millennium with an in depth interview on what the next 1000 years will bring with our favorite visionary...Bill Gates.
Perhaps it's time I get to bed.
Re:Com'on, everybody knows this! (Score:2)
I have to admit that I laughed pretty hard when I saw this. :->
The exact second when... (Score:2)
It is probably more a local time issue (Score:2)
Shall we track it here? (Score:4)
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.
True Here (Score:2)
Bzzzt try again... (Score:2)
the nasty guy for 2038 is the time function
there are functions in unix (gettimeofday for example) that at least on some platforms defines the seconds as a long, so on 64-bit you get a lot of room...
and time() is available under all win32 compilers I know of, so it comes down to the API called.
Re:Bzzzt try again... (Score:2)
Re:I thought I was certain (Score:2)
There are even weird systems out there. DomainOS used signed 32 bit to count 1/4 seconds since 1/1/1980 (or something like that). They rolled over in Nov. 1997, and are still running fine.
--Kevin, in Vegas, waiting for the party to begin.
Re:Yup 19K and 100 vs 00 (Score:2)
http://www.swissinfo.net/cgi/worldtime/clock.pl
Re:The Term Y2K (Score:2)
Re:FLAMEBAIT HERE PLEASE (Score:2)
All the action happens Friday night (more or less). It's not our fault there was no year 0. It was the ancient Romans' with their clunky Roman numerals. If their math had been up to spec we wouldn't be having this problem now.
2001 is going to be a non-event.
But sometimes it does! (Score:2)
The point of the above discussion is that even "sophisticated" systems (it was all written in C), can have Y2K-type bugs, especially if the original programmers wrote with the idea that "this software will only be used for a few years".
By the way, the solution I chose was extremely inelegant, but it works. The system times were set back 16 years. This gets the leap year right, but the day of the week is off by one. But none of the applications cared about the day of the week, except that the automatic spring-ahead and fall-back for savings and standard time occur on Saturday when the systems think its Sunday. The applications were modified to add back the 16 years appropriately. And since these old OS's are NOT Y2K ready, my systems will gracefully transition from 1983 to 1984 tomorrow night, just like they did 16 years ago. I chose 16 years, versus 28 years for a "time bridge" (28 years would get the day of the week right), because the legacy systems also interface to some old 486 PC's running DOS 5.0, and their BIOS cannot be set back before 1980, nor can they go beyond 12/31/1999. So, these systems are also running 16 years in the past. And no, these 486's cannot be simply upgraded for a bunch of other legacy hardware issues.
The only systems which I have running without the time bridge kludge are my Linux boxes, some of which have been running almost continuously since 1994 with the 0.99 (now 2.2.10) kernel.
Re:FLAMEBAIT HERE PLEASE (Score:2)
Bwah. Let's not confuse the "y2k thing" with the "new millenium" discussion.
"y2k" is happening this year. Duh.
The "new millenium" is technically not starting until 2001, and then only for people using the Gregorian calendar--though it's prolly worth noting that most of the world does submit themselves to Gregorian dates at least part of the time.
In so far as perception is reality, though, 2000 is the benchmark year for the western world. Like it or not, it's what almost everybody is identifying as the Fresh Start point, the year when we enter a new age of. . . well, whatever
Culturally, the "new millenium" starts in just over a day, and the calendar nazis be damned.