Feeds

Transmeta screws up on Y2K – Where's Man Friday when you need him?

And good news on VCR bug

  • alert
  • submit to reddit

Providing a secure and efficient Helpdesk

Updated This is absolutely the last update on this lengthy Y2K story on The Register you will see this year, unless people fix the bugs real quick.

First an update on VCRs. A technical support reader in Kenya reports that you don't have to worry too much about your auto-set date, because this year's calendar is the same as 1972's. We've checked the dates and it's all true.

Transmeta, the chip flavour of 1999, has, however, screwed up big time. A number of readers have advised us to look at the source code on its HTML site. You will remember that Transmeta was the secret site to end all secret sites? Well, unless the code monkeys have got to it yet, the HTML does have a bug. Here at The Register we're looking forward to Good Friday, and before that the 29th of February, which programmers worldwide also seem to have overlooked...

A reader from MIT reports that cable TV is not working too well in what he describes as "his neck of the woods". He reports that a company called Infomoguls (?!?) was down for two to three days. Infomogul was unavailable for comment at press time. He added: "I was disappointed to conclude that the quality of television programming will apparently not improve for the next 171 centuries!" ®

3 January 2000

Ah, the trail of the lonesome date never seems to stop and here's our early morning clutch of candidates the 3rd day into the 21st century. We suspect that many more will become apparent as the world begins to wake up from its collective Hogmanay stupor...

The Dot Com Guy had a severe dose of date dottiness, largely caused by the big long list of 1.3.19100s on the right of its page... The world famous Garfield site thinks that it's January 3, 3900. And this Seinfeld page has gone 192000 crazy, at time of writing...

Hacks are far from infallible (No kidding, Ed). Check out the UK-based Oldham Chronicle which is reporting the date as Monday, January 03, 202000... HP's site clicked over to read January 1, ***DATE INVALID***, but Carly F's boys got to it pretty quickly and cleaned up its act three hours after it bombed.

And Microsoft (again), is still screwing up on its wondrous Terraserver site, which had shown the year as 19100 for the first two days of this century, but decided to up the ante today by going for the 192000 number. How many gazillions of dollars will the Gates family be worth by then? Interested in the next generation of online finance?

Go then to E-Charge, which agrees that the year is 192000. At ACD Systems it's also 192000 (this one is getting more popular), but compounded by the fact that this company has a little logo which says "Bug Free" in the top left of its page. At Nerdperfect there was a Nerdimperfect 1900 date shown, but it's fixed now, we thought. A reader points out: "Oh no it isn't..."

It's still the year 4000 at the Gigabyte motherboard site, and has been for three days now. But a couple of people have emailed us and looked at the Javascript code generating these errors - which vary between 2100 and 4000 depending on whether you're using Netscape or IE. There's a comment line in the code that says: "// standard date display function with y2k compatibility". The programmer, according to one reader, has got his knicks in a bit of a twist. He said: "I *think* the guys at Gigabyte thought they were being clever when they changed their JavaScript code from 1900+year() to 2000+year() for the changeover. You then get your dates of 2100 or 4000, depending on whether you view with IE or Netscape, as per before. They just thought it was going to be a 2-digit year, and fixed it, rather than reading the manual and seeing it was a tm_year and would go to 100..." Thanks for that.

A reader tells us that his and three of his friends' VCRs ain't working too well in this bright dawning of a new era. It's the auto set clock feature that seems to be the problem. Any more reports of this around?

And here's a groovy one we've just noticed. A story posted in Inside China Today is suggesting that the Y2K bug may have hit breathalysers in the territories...

There are Javascript bugs in both Internet Explorer and Netscape which seem to be compounding and in many cases causing these problems. See, for example, this story on Betanews about the IE 5 bug, and comments thereon. Such bugs do not explain absolutely everything in this long litany...

The Y2K Mistakes page, referred to in the body text below, seems to have doubled in size since this time yesterday, with some more outstanding examples of ineptitude from around the globe. Although many people have now fixed their date bugs, this page has screen captures of some we list on this page. Thanks, once again, to our readers, who have contributed all of the above bloomers... ®

2 January 2000

More date problems continue to roll in from readers. Slightly worryingly, Gigabyte, maker of mobos to the cognoscenti, has its English USA page showing the date as 1.1.4000, although on other pages they get slightly closer with 1.1.2100...

A reader has pointed us to this page which is a capture of Microsoft's NZ site as it rolled over to January 1, 19100. There are also problems with Microsoft Hotmail, which the company has acknowledged. The problem occurs with the Inbox dates. One reader said that he had several examples. One email which was sent and received on the 13 September 1999, now shows as being received on the 9th of November 1900.

The people over at the Millennium Experience, those of the noble Greenwich dome, have a countdown to the next millenium which appears to stand today at 364 days. How are we to interpret this one? Well, the real next millennium doesn't start until Jan 1, 2001 but everybody decided to pretend it started a few days ago. The Millennium Dome has one year to expire - in other words it will be shut down before the real new millennium starts. Or else it's a cockup. Err..it is a cockup...

Consider, this, the home of The Futurist, which is reporting that the time left to the year 2000 is "-1901 years, 11 months, 29 days, 13 hours, 32 minutes, 45 seconds".

This Pokemon site shows today's date as being the 2nd of January, 3900. We thought this might be on purpose, but Mike Galloway, at Merlin Online, has put us right. He says: "The date on the Pokémon web site is as a result of a bug in the script used to get the date. They should have used more robust checking! This sort of bug may catch many others out at well. The problem is they are using "(1900+today.getyear())" to generate the year. "This only works for years prior to 2000. For 1999 say the getyear object returns 99 so adding 1900 gives you 1999. For 2000 and later getyear returns the actual year - so of course 1900 + 2000 gives 3900." Thanks for that.

This Russian site rolled over to 2.1.100, but the problem has now been fixed. The Sherman's Lagoon cartoon site has some Y2K funnies up there, but its own archive is listing one as being dated 1/1/100. A reader says he has noticed that this date - 1/1/100 - is cropping up in reports he is creating, and wonders if there is some problem with Perl scripts causing the unusual date change.

Again, a reader comes up trumps with the answer. He says: "It's more a problem with programmers not understanding the way Unix (and Unix-based systems such as the Perl language) represent the year in dates. "Unix represent dates in a structure called tm, which has the member int tm_year; /* years since 1900 */ and consequently the Perl documentation says: * localtime EXPR "Converts a time as returned by the time function to a 9-element array with the time analyzed for the local time zone. Typically used as follows: " # 0 1 2 3 4 5 6 7 8 ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); "[...] $year is the number of years since 1900, that is, $year is 123 in year 2023, and *not* simply the last two digits of the year. If you assume it is, then you create non-Y2K-compliant programs--and you wouldn't want to do that, would you?

"Naturally, this is also the reason for the 19100 bug, where people just put 19 in front of $year when printing it.

"Naturally, the Perl community has been quite verbal about this issue for a long time now, see here."

And still on programming, surely Fujitsu should be ashamed of itself, shouldn't it? Here we have a Fujitsu Cobol support and rollover page where the date is January 2, 3900, a bit like Pokemon (above)...Fire the programmers!

The US Naval Observatory admitted that it had a similar problem to Auckland Airport, see below, and that its clocks were reporting the date as 1.1.19100. The Jack Tars are working to fix the problem. The World Metereological Organization was not content to skip 17 millenia but went for 170 millenia.

The local council at Poole, here in Blighty, failed to survive the Y2K problem at its website. Citizens! Watch out for your council tax forms. This Amiga site has a for sale section, and all postings there have flipped over to 1.1.100. Is the Amiga platform Y2K compliant, or is this site running on a PC platform, we ask ourselves.

See the This is York site for another example of Y2K failure. IRC chat at Lineone misreported the date as 1 January 19100, although this now appears to be fixed.

Reader Richard King from New Zealand (the government of which was cock-a-hoop about being the first industrialised country to report no glitches) writes: "According to the TV, the biggest Y2K related problem in New Zealand is that some Wellington bus-pass validating machines were not accepting passes in the new millenium due to the date change.

Reports also surfaced of a 15 minute power cut in Invercargill at midnight for which the Y2K bug may or may not have been responsible. Oh, and Auckland's permanent sunshine machine had a pre-2000 rollover glitch and went into United Kingdom mode. Unfortunately this meant rain and drizzle. Fortunately the Australian responsible was fired." Richard adds that the police computer system that went down at Zero Hours on 1.1.2000 (see below), was a planned outage. However, the IT department neglected to tell the cops it was happening!

But there's a similar problem in Australia. A reader tells us that the public transport ticketing system has failed in two states, Tasmania and South Australia. Another Australian reader writes to respond to the NZ sunshine problem, above. He says: "If it had been an Australian running their stupid "sunshine machine", it would have been fine. The problem is the fact that they're being left to run their own country. Take a look at all the Y2K problems you've got listed, and look how many of them are from New Zealand. Considering their size, they're scoring incredibly well."

The spin doctors at this site would have us believe it is the 2nd of January 3900. AOL has had its problems too. Netfind has decided to date itself as 19100, while there are also one or two glitches in chat room 1, and emails are being transmitted very slowly...

Chris Moyles, a DJ at BBC Radio One, mentioned the small problem the station had with its website on his programme yesterday (see below), and the BBC has now fixed the problem, but its first stab at a fix was to put the date as 1 January 0020...

ZDNet reported seven US nuclear power stations had "minor" Y2K glitches, while there were two reports from Japan on the 1st of January of problems with monitoring systems, one of which related to a nuclear power station.

Bloomberg reported today that up to a dozen Japanese brokerages have had "minor" problems with Y2K dates developed by Nomura.

Finally, and partly because we're getting a tad bored of this, check out the Y2K mistake site, which lists many many more Y2K problems, with screenshots so the guilty cannot escape, and includes our own page - our datestamp rolled over from 31/12/99 to 1/1/0. Yes, your La Registra was in Year Zero, but we've now fixed the problem. Cough..

Very many thanks to all of our readers for notifying us of the glitches. Over the past three days, the list has, rather alarmingly, got pretty long, leading us to think that we'll see very many more glitches in the future, and many probably more serious than the examples we've posted. All of these "minor" glitches are now beginning to mount up to something less than "minor".

As we were ready to pack in for today, one of our readers kindly sent us a link to this Washington Post piece which suggests that the Pentagon withheld a serious glitch caused to one of its satellite systems at rollover time...

Please keep your reports coming... ®

Other date stamp problems below...

1 January 2000

The whole of the world+dog seemed to roll over into the year 2000 with little sign of catastrophes predicted by people in the computing industry who, let's face it, had something of an axe to grind anyway. But spare a snicker for the head of technology at the BBC, who after the UK celebrations last night was heard on Radio Five Live celebrating his and his team's victory over the said Y2K bug. Alas, the BBC Radio One home page this morning shows the following... Many readers reported that Apple's dates were also slightly screwed, with its Web site showing that the year at clickover was 20100. That now seems to be fixed. And again, relating to Apple, we have had a message from a reader who notes: "It looks like the popular Macintosh Web server Quid Pro Quo from Social Engineering (http://www.socialeng.com/) is not entirely Y2K compliant. All requests to my QPQ-based Web server post-midnight are now recorded as having taken place on January 1, 100, as the date change just added one year to December 31, 99." Over at hacker-oriented site 2600.COM there's this message: "The date specified (01-01-1900) is impossible. If you have forced this error condition, you may be in violation of state, federal, and/or civil laws. Those outside the United States should check with their respective governments concerning their country's extradition treaty. Dissemination of this error is also strictly prohibited." We think this might be a joke... The Klingons need have no fear because Star Trek is not Y2K compliant. According to a page on the Star Trek site, the next episode is due on 1/1/1900.

In other news, Old Mother Shipton, the Seeress of Knaresborough, was fired by The Register for wrongfully predicting the world would end in 1999. Yesterday's Y2K snippets are below... ®

31 December 1999

We'll update our site throughout the day as various parts of the world click over into the Year 2000, but our first sighting today is one of the better ones. At the Swiss Info site, there is a clock which is currently reporting that the time in Chatham, New Zealand, is Saturday, January the 1st, 19100. Check out the link to here, if the boffins haven't fixed it yet.

Thanks to reader Wim Verveen for forwarding this one from Russ Cooper, editor of NTBugTraq. The boffins fixed it four and a half hours after the original story was posted, but not before Melbourne reported the same problem.

New Zealand's own Y2K page, which has already proved Mother Shipton wrong, can be found here. Although the authorities in NZ reported the arrival of the 21st century brought no Y2K problems, the New Zealand Herald is reporting a power outage and the downing of a police computer in the country. The story is here. Auckland Airport reported: "No problems so far" and spoilt that by posting the date as the 1st of Jan, 100... Australia, the next largest industrialised country to tick over also said there had been no problems so far. . ®

Providing a secure and efficient Helpdesk

More from The Register

next story
Phones 4u slips into administration after EE cuts ties with Brit mobe retailer
More than 5,500 jobs could be axed if rescue mission fails
Israeli spies rebel over mass-snooping on innocent Palestinians
'Disciplinary treatment will be sharp and clear' vow spy-chiefs
Apple CEO Tim Cook: TV is TERRIBLE and stuck in the 1970s
The iKing thinks telly is far too fiddly and ugly – basically, iTunes
Huawei ditches new Windows Phone mobe plans, blames poor sales
Giganto mobe firm slams door shut on Microsoft. OH DEAR
Phones 4u website DIES as wounded mobe retailer struggles to stay above water
Founder blames 'ruthless network partners' for implosion
Found inside ISIS terror chap's laptop: CELINE DION tunes
REPORT: Stash of terrorist material found in Syria Dell box
Show us your Five-Eyes SECRETS says Privacy International
Refusal to disclose GCHQ canteen menus and prices triggers Euro Human Rights Court action
prev story

Whitepapers

Secure remote control for conventional and virtual desktops
Balancing user privacy and privileged access, in accordance with compliance frameworks and legislation. Evaluating any potential remote control choice.
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.