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?
..Yawn. As far as things go, and it's been shown, Millenium Bugs (what a bad name for it) can really start kicking in anytime. I hardly think every computer does every calculation based on Here&Now. Calculations for the future are done, and theoretically, should have already encountered some zeros in the date.
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 as they poke fun of the Y2K paranoid.
Thank you for your support.
A millennium that doesn't 'N'?
----
----
Open mind, insert foot.
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.
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
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.
--
Linux user since early January 1992.
--
Linux user since early January 1992.
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.
To further confuse matters, UTC includes leap seconds but GPS time does not so they are off by 13 seconds IIRC (NTP servers obviously correct for this).
--
"L'IT c'est moi!"
Redhat just put out an update for sharutils.
Anyone else see any last minute updates?
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?
12-31-1999 00:00:00 :-)
That's Komedy.
Oh, it was never my show anyway :)
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 ?
Nope. Sure it's a problem, but nobody gets hurt, planes don't fall out of the sky.
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.
Y2K will begin on January 1, 1900!
Bruce Perens.
Who cares? Every organisation worth a damn has people on call for days after the rollover. I don't believe anything serious is going to happen in countries like Australia, the UK and the US. If it does, well, I welcome the oncoming of our new insect overlords.
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.
I say I ain't giving you no tree fiddy you goddamned Loch Ness monster, get yo own goddamned money!
That's what I believed when I first about Y2K ... and then I learnt that as far as 3 years ago a significant number of credit card terminals started crashing when presented with a card expiring in 00 ... duh! They were brand new ...
Because back in year 0, people did'nt even know 0 existed! That's right! They had no idea! It's a bit like, until someone discovered oxygen, people could'nt breath! All hail Lavoisier! /millenn?ium/ must start in 2010!
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!
What would that be in Star-Date?
Chas - The one, the only.
THANK GOD!!!
Chas - The one, the only.
THANK GOD!!!
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
Editor, A1-AAA AmeriCaptions
Those are the two most likely errors IMO to be missed in testing. 19K because the people looking at them thought, "4-digit year, that is OK", and 100 vs 00 because until now it has always been easiest to look for a 2-digit year and produce a year that will go from 2 to 3 digits...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Unless, of course, the KDE crowd secretly plans to release something called Y2KDE Saturday, in which caseyour post is the only one here that is ON-topic, and I owe you a most abject apology. ;-)
:-)
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
That is the common decision, and then they make a new type named something like long-long which is 64 bit.
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
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
Banks ran into this a long time ago, to print out mortgage payment tables. Credit card expiration dates past 12/1999 caused many a hurried upgrade several years ago. I'm sure insurance companies, pension plans, etc, all had their little moments of enlightenment.
--
Infuriate left and right
2^10 or 1024
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
-fb Everything not expressly forbidden is now mandatory.
Okay, in some expressions, ^ means XOR.
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.
-fb Everything not expressly forbidden is now mandatory.
One man's nuisance is another man's catastrophe.
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.
-fb Everything not expressly forbidden is now mandatory.
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.)
The frogs^H^H^H^H^HInternational Earth Rotation Service (IERS) controls UTC.
Mea navis aericumbens anguillis abundat
Numerous problems showed up in the USA when they first started issuing credit cards with 2000 expiration dates. VISA and Mastercard spent a great deal of time and money on fixing the problem. Many of the credit card validation terminals were broken and had to be upgraded or replaced, not to mention the software in the banks.
Mea navis aericumbens anguillis abundat
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.
Mea navis aericumbens anguillis abundat
I have an old 68010 Unix development system with a release of SCCS (source code control system) that stops working as of 2000-01-01. All of the SCCS commands fail with fatal errors. The system is too old to be upgraded.
Mea navis aericumbens anguillis abundat
Off topic I know, but I thought it was particularly amusing.
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
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
Are you sure about that? I thought n_time and friends where all uint32's? Even on the 64bit platforms...
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
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.
Y2K issues have already walloped Microsoft, at least according to the fine folks at memepool who snagged this screenshot. ;-)
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
Someone needs to give Rob a map showing the bloody international date line. NZ will be 2 hours into Y2K before Sydney, Australia even thinks about it. And some 18 hours before the West Coast of the US. So us suckers get to test all the vendors Y2K ready systems.... Tell you about it in 8 hours time.
There's absolutely no excuse for that nonsense, and you are doing your students a gross disservice.
"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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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
Comment removed based on user account deletion
I was watching the local 24 hour news channel in Tampa this afternoon, and they were holding a press conference to say how Y2K compliant they were, and that was one of the main points they stressed, don't pick up your phone to see if there is a dial tone. It makes a lot of sense to me. Of course, you just know somewhere people will do 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).
Is there a link anywhere that says when the New Year hits in different major cities across the world? One that is set for an American zone, but lists the cities, for instance like Greenwhich at 7 PM Eastern. Or heck, just for starters, at what time in Eastren time does Y2K FIRST start over in the Pacific?
"and that was one of the main points they stressed, don't pick up your phone to see if there is a dial tone. It makes a lot of sense to me. Of course, you just know somewhere people will do
/don't/ want, is everybody in New York State turning all their electricity off, and then on again on 1/1/2000:00:00:01
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
It's 10 PM. Do you know if you're un-American?
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.)
Dunno if this counts, but Boris Yeltsin just resigned about 10 minutes ago as President of Russia. Offtopic, right? Well...maybe it's just me, but has anyone else noticed that he looks remarkably like a (poorly-debugged drunken) cyborg??
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.
Oh, thats an easy one. The second a stray bullet damages property you own or when the first molotov cocktail explodes in your neighborhood.
There is a reason that Y2K problems are going to be primarily local time issues. The problem is in the representation of dates for human readability in many cases. Those are scattered through many user interfaces, reports, etc. Not all of them will have been fixed. But they are communicating with users, usually in their own local time.
The net will not be what we demand, but what we make it. Build it well.
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.
I work for a purty bug ISP, no not the big big ones, but a decent sized one and all our srvers run on GMT so I will be covering from 10AM-6PM and 8PM-2AM mainly so I can watch our server farm. We are EST (GMT -5).
www.mp3.com/Undocumented
uhh.. not exactly...
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.
I belive it's because someone trademarked the word 'year 2000' of course this could also be an urban legend
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.