Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
News

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?
This discussion has been archived. No new comments can be posted.

When Does Y2K Begin?

Comments Filter:
  • by Anonymous Coward
    Cool. Wonder what that sounds like?

    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

  • by Anonymous Coward
    You would be surprized. There are a number of systems at MCI in their revenue ops environments and with the older MCI Mail systems that were written with 3-digit date formats. From what I saw it looked like an early attempt (mid 80's) to code for the Y2K problems. Pretty stupid though, they had to port them all anyway.
  • by Anonymous Coward
    Yes well if you want to follow the bible it's a year 2004 crisis we're going into.....
  • by Anonymous Coward
    I found that I had to be quite intoxicated to kiss your SO too.
  • by Anonymous Coward
    We don't count a one until something is finished. You're not a year old until you've been alive for a year, and 2000 years isn't finished until the start of 2001.
  • by Anonymous Coward
    ..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 [userfriendly.org] as they poke fun of the Y2K paranoid.
  • by Anonymous Coward on Thursday December 30, 1999 @03:02PM (#1430499)
    Place all the "You are such a stupid shit, everyone with my intellect knows the Millennium starts next year" Comments under this thread.

    Thank you for your support.

  • A millennium that doesn't 'N'?

    ----
  • by Gleef ( 86 ) on Thursday December 30, 1999 @05:07PM (#1430501) Homepage
    There's a very good World-Wide countdown clock at Time and Date [timeanddate.com] (they also have a non-java version [timeanddate.com]). 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 [timeanddate.com] :-)

    ----
  • I have to get laid before the world ends, so I'm gonna try the old fasion way and if that dosen't work about 1 hour before the world ends what ever time it maybe I'll have to find a house of ill repute.

    I guess I should probably just find a house of ill repute cause it'll take me quite a while in Fort Myers.
  • I'm glad somebody noticed the posting time. I couldn't resist...

    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

  • Frankly, this is one of the most concise summaries I've read on slasdot ot date. Bravo.
  • Godamnit Slashdot.

    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.
  • Sorry to be late with this reply, but the SCCS bug I mentioned was not an "output only bug". It totally refused to check in files, claiming that the so-called s-file was corrupt.

    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.

    --

  • This is exactly the bug I ran into.

    --

  • by mce ( 509 ) on Thursday December 30, 1999 @03:40PM (#1430508) Homepage Journal
    I hate to rain on your show, but I have had some first hand experiences with software written in C that did contain The Bug. There is more badly written software out there than even many people in the IT industry can imagine.

    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).

    --

  • The US Naval Observatory [navy.mil] has some interesting stuff - including a decent discussion on the location of the "sunrise for the new millenium".
  • From http://astro.nmsu.edu/~lhuber/leaphist.html [nmsu.edu] The Gregorian calendar is thus based on a cycle of 400 years, which comprises 146097 days. Since 146097 is evenly divisible by 7, the Gregorian civil calendar exactly repeats after 400 years. Dividing 146097 by 400 yields an average length of 365.2425 days per calendar year, which is a close approximation to the length of the tropical year. Comparison with Equation 1.1-1 reveals that the Gregorian calendar accumulates an error of one day in about 2500 years. Although various adjustments to the leap-year system have been proposed, none has been instituted.

    ----------------
  • 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).
    --
  • by marcus ( 1916 )
    ...It happened to me last year. I had just received a nice shiny new ATM card from my bank. Everything was fine until I went travelling on business. Upon arrival, all the ATM machines that I tried told me that my card had expired(Exp. date: March '01). Upon return, my card worked as before. Subsequently, during another visit to the same customer, the ATMs(at least the first one I tried) worked properly.

  • And the power's still on, my computer stayed up, and the modem stayed online.

    (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!

  • People believe worse than that... ten years or so ago, in church, I overheard a woman stating seriously that computers are the Beast (of Revelation) because they use 9s and 6s to represent data. (666, get it?) Computers use 9s and 6s because a 6 is an upside down 9.

    This is true, I swear I am not making this up. And I've yet to hear a clueless luser story that tops it :-)
  • My university (in fact, the entire university system) is shutting down for fear of "hackers" (their term) not so much for the Y2K bug.

    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.
  • Yes, but did your announcement email arrive in your mailbox at 4am on the 31st of December? (GMT+11)
  • Redhat just put out an update for sharutils [lwn.net].

    Anyone else see any last minute updates?
  • by Bradley ( 2330 ) on Thursday December 30, 1999 @04:07PM (#1430518)
    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 [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?
  • Well from what I have seen most people dont have their clocks set right anyway. I figure just as much might happen next week as will happen at local midnight or 00:00 GMT or whatever.
  • Well, looks like we're all well prepared.

    You can pat yourselves on the back and take those enormous paycheques home now..

  • Not to worry - his English was not that good either. ("Here, here.")

    -tor
  • 12-31-1999 00:00:00
    That's Komedy. :-)
  • Y2K is a scam.

    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/whateverthehellyouthoug htwouldhappen, I'd be happy to receive donations ;)
  • 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.
  • 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.

  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Thursday December 30, 1999 @04:02PM (#1430528) Homepage Journal
    Y2K will begin on January 1, 1900!
  • 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.
  • Of course you do realise that 00:00:00 would be the start of the day.. so your post was dated this morning, new years eve and not new years day.

    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!
  • 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!
    Now, you may ask, did people in year 10 knew they were in year 10? No, they did'nt! So the /millenn?ium/ must start in 2010!
    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!!!
  • 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

  • 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
  • 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
  • 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
  • by tilly ( 7530 ) on Thursday December 30, 1999 @03:32PM (#1430551)
    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
  • by tilly ( 7530 ) on Thursday December 30, 1999 @05:53PM (#1430552)
    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
  • by tilly ( 7530 ) on Thursday December 30, 1999 @03:30PM (#1430553)
    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 [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.
  • 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.

    --
  • 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


  • 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.
  • 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.

  • 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.)
  • Ah yes, the Y+1C bug. I've been promoting this for a while, but no one listens.

    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

  • Why would programmers worry about 1900 and 2100, and forget about 2000?

    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 was replaced by UTC back in 1972. People may refer to GMT for reasons of nostalgia or nationalism, but it is dead, dead, dead.

    The frogs^H^H^H^H^HInternational Earth Rotation Service (IERS) controls UTC.

  • 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.
  • The biggest threat is going to be from lunatics who are going to assume that bank alarms etc. won't work and go out and act like juvenile delinquents on halloween.

    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.

  • 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.
  • Microsoft defines a long as 32-bits in Win64. They say they did this to make it easier to port Win32 programs to Win64.
  • believes that some areas may be without gravity.

    Off topic I know, but I thought it was particularly amusing.

  • by warlock ( 14079 ) on Thursday December 30, 1999 @05:29PM (#1430591) Homepage
    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
  • by Roundeye ( 16278 ) on Thursday December 30, 1999 @08:19PM (#1430595) Homepage
    About 15 years ago a friend and I (while in grade school) called the Royal Greenwich Observatory (from Kentucky) to set our watches by the official observatory clock -- so we could be exactly on GMT (ah the days before I knew about NTP!). We ended up talking to the janitor there (it was about 3am there) who finally (after some pleading) shambled off to take a look at the clock, shambled back and told me, "it's about 3:15".

    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. :-)

  • by B.D.Mills ( 18626 ) on Thursday December 30, 1999 @07:20PM (#1430599)
    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.
  • by B.D.Mills ( 18626 ) on Thursday December 30, 1999 @10:33PM (#1430600)
    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).
  • Are you sure about that? I thought n_time and friends where all uint32's? Even on the 64bit platforms...
  • by DragonHawk ( 21256 ) on Thursday December 30, 1999 @06:24PM (#1430607) Homepage Journal
    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.
  • by toastyman ( 23954 ) <toasty@dragondata.com> on Thursday December 30, 1999 @04:10PM (#1430612) Homepage

    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
  • by Cef ( 28324 ) on Thursday December 30, 1999 @06:22PM (#1430622)

    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..

    • Every year evenly divisable by 4,
    • Unless it is a year ending in 00 (Century),
    • Unless that year is also divisable by 400.

    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.

  • by David A. Madore ( 30444 ) on Friday December 31, 1999 @07:52AM (#1430627) Homepage

    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.

  • Y2K issues have already walloped Microsoft, at least according to the fine folks at memepool who snagged this screenshot [memepool.com]. ;-)
  • 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.
  • by coyote-san ( 38515 ) on Thursday December 30, 1999 @03:25PM (#1430644)
    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.)
  • I just have to include a link:
    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.
  • 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?
  • "I agree. I've witnessed localized gravity shifts occurring for years. You know they happen when you stumble while you walk or when you or a friend is just standing around and suddenly falls over or at least has to take a step to catch themselves."

    Or when you step out of a HomeStyle Buffet or Ponderosa and leave footprints in the asphalt.

    Jazilla.org - the Java Mozilla [sourceforge.net]
  • "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)."

    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 /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

    Jazilla.org - the Java Mozilla [sourceforge.net]
  • There was no year 0, the calendar started with 1 A.D. Supposedly based on the birth of Christ, but the guy that calculated it was off by four odd years.

    --GnrcMan--
  • Yup. We'll see this all over the place, again and again. Whoever uses a struct tm unaltered is subject to this.
  • perl -e 'print 2^10';

    If you read 'man perlop' you will find that ^ in perl is a bitwise XOR and NOT for evaluating powers of numbers.

    Here you go:
    for $i ( 0 .. 3 ) {
    printf "2 to the 10 * %d is %10d\n", $i, 2 ** (10 * $i);
    }

    2 to the 10 * 0 is1
    2 to the 10 * 1 is1024
    2 to the 10 * 2 is1048576
    2 to the 10 * 3 is 1073741824

  • by Tom Christiansen ( 54829 ) <tchrist@perl.com> on Thursday December 30, 1999 @04:20PM (#1430672) Homepage
    Y2K will begin on January 1, 1900!
    I think you mean: Y2K will begin on January 1, 19100! , as in:
    #include <time.h>

    char *months[] = {
    "January", "February", "March", "April", "May ", "June",
    "July ", "August", "September", "October", "November", "December",
    };

    main() {
    time_t now = time(0);
    struct tm *t = localtime(&now);
    printf("Y2K will begin on %s %d, 19%02d\n",
    months[t->tm_mon], t->tm_mday, t->tm_year);
    exit(0);
    }

    Mark my words: the Y19K errors are on their way. :-(
  • by tytso ( 63275 ) on Thursday December 30, 1999 @03:20PM (#1430679) Homepage

    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.)

  • by PurpleBob ( 63566 ) on Thursday December 30, 1999 @03:46PM (#1430680)
    Au contraire, I think that as soon as we get through 2000, everyone will say "Oops, we were wrong" so they can party again in 2001.
    --
  • 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.
  • Friday's User Friendly Comic Strip [userfriendly.org] has an interesting take on when Y2K starts.

    I have to admit that I laughed pretty hard when I saw this. :->

  • 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.
  • by dsplat ( 73054 ) on Thursday December 30, 1999 @03:36PM (#1430701)
    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.
  • 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).
  • 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.
  • yes filesystems will have probelms, but guess what so will NT as a lot of the API's you call won't vut it even if the underlying FS does (not sure on NTFS... would have to look it up)
  • 32 bit dies in 2038 because a long on a 32 bit machine is...32 bits. On a 64 bit machine, you won't need to worry anytime soon (assuming the compiler defines long as 64 bit which would be expected).

    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.
  • yep, you called it. check it out...it's been 2000 in new zealand for about 25 minutes:

    http://www.swissinfo.net/cgi/worldtime/clock.pl? Chatham,New=Zealand
  • I belive it's because someone trademarked the word 'year 2000' of course this could also be an urban legend
  • Where's the beef?
    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.
  • I had to address a Y2K-like problem back in 1997. I had inherited a large custom software system written in the early eighties for a ten-year project. The project went past the projected end of life, and in early 1997, I was horrified to discover that the system would stop working on 27 November 1997 at 1600. The system timestamps used two 16-bit signed integers. One of the signed shorts contained the number of 8-hour time periods since 0000 on 1 January 1968 (this was not a Unix system). Well, the number of 1/3 days since 1 Jan 1968 becomes greater than 31767 on the meltdown date. And, it was not a simple matter of making all the time stamps unsigned integers, since a lot of legacy code assumed that the data could only be signed data. Needless to say, I had some work to do in the summer of '97.

    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.

  • 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.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...