Microsoft Issues Workaround For Zune Freeze

UnknowingFool writes "As a followup to the Zune New Year's Eve meltdown, Microsoft has issued a workaround for what some users have correctly guessed was a bug caused by a leap year. To recover from the problem, let the Zune drain the batteries and restart it after noon on January 1, 2009. Many sites are reporting that Microsoft has 'fixed' the issue, but technically all Microsoft has done is to ask users to wait out the conditions that triggered the bug. Unless a software patch comes out, Zunes will suffer the same problem again in four years." Reader ndtechnologies adds, "According to posts in the Toshiba forum at anythingbutipod.com, the same bug that shut down millions of Zune 30's also affects the Toshiba Gigabeat S. The Zune 30 is based off of the Gigabeat S series and was co-developed by Microsoft with Toshiba."

Comments

It probably won't last another 4 years

[thetoadwarrior]

So this is an acceptable solution.

Re:It probably won't last another 4 years

[Sancho]

After all the hell that people give Microsoft for not supporting a 9 year old OS? Yeah, right.

Besides, I know people who still have first generation iPods.

Re:It probably won't last another 4 years

[ccguy]

Besides, I know people who still have first generation iPods.

And if they broke, would they expect apple to fix them?

Suppose instead of this being Zune's firmware it was a microwave you bought 5 years ago. Would you have any claim to have it fixed (out of warranty, etc).

Re:It probably won't last another 4 years

[Anonymous Coward]

C'est quoi ça veut dire, "écouter de la mine" ?!

Re:It probably won't last another 4 years

[Tubal-Cain]

Microwaves do not lock up because of leap year issues.

Re:It probably won't last another 4 years

[datajack]

The difference being that microwaves suffer wear and tear and can develop a fault after five years.

This is software, the fault was there when it was purchased.

Re:It probably won't last another 4 years

[mindwhip]

The microwave failure would be acceptable wear and tear. The Zune was in effect sold with a predictable and correctable flaw (leap years are very predictable), causing it fail out with normal wear and tear, which would class it as defective product.

In UK law at least this is a significant difference... you can never tell in the US though.

Re:It probably won't last another 4 years

[Pentium100]

You can get the microwave (or a tape recorder, or a VCR) fixed by a third party (or do it yourself) depending on what part has broken.

Only Microsoft can fix these firmware issues. If the source code for the firmware was publicly available, someone could fix the problem and distribute the fixed firmware for free or for money, but since it isn't, only MS can patch it.

Re:It probably won't last another 4 years

[witherstaff]

Why are consumer electronics any different than any other product? Let's talk about items costing less than a laptop, so less than 2000.

Would you accept if your 5 year old ___ broke , was unfixable, and needed a new replacement?

• Home Furnace
• Central Air
• Oven
• Refrigerator
• Bike

You get the picture. Why are electronic manufactures exempt from shoddy products that don't have some sort of reasonable lifespan? Not wear and tear or dropping a product, just the product becoming unusable due to the product having some bug/feature to break it outright like the Zune.

As to a microwave, a 5 year old whirlpool oven broke on me and they no longer had replacement circuit boards. Whirlpool expects their products to have at least a 10 year lifespan. They pro-rated my equipment and sold a new unit, installed, for 33% of the cost. Now that's an acceptable solution for shoddy workmanship.

Re:It probably won't last another 4 years

[bobstreo]

I have a 22+ year old microwave that won't die.

Unfortunately, it doesn't work correctly with PlaysForSure, no matter how many times I've called Microsoft.

Now, that being said, I am on month 7 trying to get xbox support to RMA me a 360 wireless dongle.

Re:It probably won't last another 4 years

[SimonTheSoundMan]

If the microwave was only 5 years old and it broke down, you are covered in England and Wales by consumer protection laws if it less than six years old and it break down. Just as long as you can prove it was not accidental damage, your covered for a free repair. :)

Just something for the UK readers here. Covers anything electronic.

Re:It probably won't last another 4 years

[mustafap]

>Why are electronic manufactures exempt from shoddy products that don't have some sort of reasonable lifespan

Because collectively we accept this. Sad but true.

Re:It probably won't last another 4 years

[SimonTheSoundMan]

I should proof read too, my grammar and spelling is awful today.

Re:It probably won't last another 4 years

[falcon5768]

Expect no, will get? usually. Apple has either repaired or given a reduced price on a replacement iPod to 1st gen owners for a few years now.

Re:It probably won't last another 4 years

[91degrees]

But after 4 years, you don't have an automatic right to a refund. It would be reasonable for the retailer to repair it (which would simply involve applying this workaround). Alternatively a partial refund of 1/1461 times the price of a new Zune. That could be as much as £1.37.

Re:It probably won't last another 4 years

[91degrees]

That could be as much as £1.37.

Uhm... I mean 13.6p. I made a typo in calc.exe (and it turns out my mental arithmetic is abysmal).

Re:It probably won't last another 4 years

[gparent]

Which they will. So I don't see how this is a big issue.

Re:It probably won't last another 4 years

[Idaho]

Suppose instead of this being Zune's firmware it was a microwave you bought 5 years ago. Would you have any claim to have it fixed (out of warranty, etc).

In the case of a microwave or similar household appliance (dish washer, washing machine, fridge etc.), if it breaks within only 5 years or even less from mechanical failure I'd never buy that brand again. If it breaks due to what is obviously a (software) design flaw that the manufacturer subsequently refuses to address (at their cost), same story.

Such stuff should be designed to last 10 years or more given normal usage. If it is designed to break in less than 5 years I ain't buying that shit.

Re:It probably won't last another 4 years

[Anonymous Coward]

Actually, if you RTFA, they haven't, and won't.

MS does NOT like you. They feel no obligation to help you in any way. Until and unless the cost of leaving it alone outweighs the cost of fixing it (lawsuit vs. bad press), they will do NOTHING.

Re:It probably won't last another 4 years

[Insanity Defense]

You can get the microwave (or a tape recorder, or a VCR) fixed by a third party (or do it yourself) depending on what part has broken.

Only Microsoft can fix these firmware issues. If the source code for the firmware was publicly available, someone could fix the problem and distribute the fixed firmware for free or for money, but since it isn't, only MS can patch it.

Which they will. So I don't see how this is a big issue.

Has Microsoft stated they will do the fix or are you just assuming that Microsoft will do the right thing?

Re:It probably won't last another 4 years

[Leif_Bloomquist]

My microwave has a firmware bug. After I heat something, if the next button on the keypad I press is anything other than "Reset", it locks up. It's incredibly irritating (since I'm usually putting something else in and trying to enter a new cooking time). That said, the microwave cost under $50...

Re:It probably won't last another 4 years

[capnkr]

Plus, this 'fix' will adversely affect the battery, shortening it's life and/or lessening capacity. Draining a battery to dead flat is never good. Having to do it to 'fix' a bug is like adding insult to injury (to Zune owners).

Re:It probably won't last another 4 years

[Anonymous Coward]

My analog cell phone still worked, but that doesn't mean I expect to keep using it.
 
  I reckon it's more useful countering the effects of global warming by contributing to the land-mass that's above sea level.

Re:It probably won't last another 4 years

[Paradise Pete]

The Zune was in effect sold with a predictable and correctable flaw

And if you look at the bug in the code (line 259) it's atrocious. Something a junior programmer would be embarrassed about.

When days is 366 it causes an infinite loop. And also note that simply changing line 263 to use 365 causes a different bug. So the whole approach is wrong. It ought to simply be

while (days > daysInYear(year))
{
days -= daysInYear(year);
year += 1;
}

Re:It probably won't last another 4 years

[Malevolyn]

I actually brought in a semi-broken iPod with obvious firmware modifications and they still replaced it free of charge. Oh, and yes, it was out of warranty.

Re:It probably won't last another 4 years

[harry666t]

Apropos microwaves and mp3 players... I've got a 20 years old Samsung microwave (it's almost older than myself) and it hadn't suffered from any failures throughout its whole lifetime, and is simply Still Working. Amazing, compared to my Sandisk Sansa C150 mp3 player that I had to replace after two weeks because of some software bug that permanently froze the device...

It's sometimes funny how >15 yro devices outlive new products.

Re:It probably won't last another 4 years

[AgentX24]

Why is it a loop anyway when it's only a one hit event? Surely an if would have been better?

Re:It probably won't last another 4 years

[Anonymous Coward]

If the source code for the firmware was publicly available, someone could fix the problem and distribute the fixed firmware for free or for money, but since it isn't, only MS can patch it.

You mean open source right? aha you insensitive clod.

Re:It probably won't last another 4 years

[Anonymous Coward]

install netBSD...

Re:It probably won't last another 4 years

[gparent]

Well, first I was assuming they would do the right thing, because it's a trivial fix and it requires no effort on their part.

Secondly, they have a detailed FAQ which explains the issue in detail and how they will fix it.

Re:It probably won't last another 4 years

[Wrath0fb0b]

Why are software defects any different that hardware defects?

If my microwave had a defective gear in the motor that spins the turny-thing (technical term) that broke after warranty, I wouldn't expect it to be fixed. Is a defective line of code somewhere really all that different?

Re:It probably won't last another 4 years

[camperslo]

I have a 22+ year old microwave that won't die.

Unfortunately, it doesn't work correctly with PlaysForSure, no matter how many times I've called Microsoft.

Place a cup of water in the oven along with the PlaysForSure device to avoid possible problems from excessive standing waves..

Some microwaves do last a very long time. It wasn't that long ago I finally stopped using one that had a mechanical timer. Except for not having a rotating tray, I really liked it.
With no standby power for control electronics I figured I saved $1 a month in power for many years.

Many people cause premature failure of microwave ovens by routinely hitting the button that opens the door before the oven has stopped or they've hit stop. In many ovens that eventually causes the contacts in one of the door-interlock safety switches to burn up from directly interrupting the incoming power to the magnetron supply. It's a very simple fix, but most people don't know how or bother.

Re:It probably won't last another 4 years

[RulerOf]

Draining a battery to dead flat is never good

Actually, in the case of Lithium Ion batteries, you should drain them every once in a while. Also, "Flat dead" for lithium ion batteries means the point at which the battery's internal circuitry stops sending power to the device--the cells themselves aren't actually dead.

Still, you should discharge fully at least once a season, and not just once a leap year :P

Re:It probably won't last another 4 years

[Paradise Pete]

Why is it a loop anyway when it's only a one hit event?

They start from 1980. You can see it on line 58.
And looking at line 59 you can see that there is planned obsolescence(!) for the year 2080. Zune owners should demand a refund ;-)

Re:It probably won't last another 4 years

[drew]

Where were you able to buy a home furnace that cost you less than 2000? My wife and I got a huge discount on our furnace (she's an architect) and we still paid a fair amount more than that. And our house is not very large. Unless you live in a condo or a small townhouse (or perhaps Florida) you're going to pay a lot more than that for a furnace.

At any rate, I don't think that the standard is all that much lower for consumer electronics in general. Last year my parents finally replaced their TV, which was only slightly younger than the furnace that my wife and I replaced around the same time. I have a 200 disk Sony CD changer that is 10 years old, and recently gutted a 22 year old CD player (that still worked) to use the case for a home theater PC.

For computer hardware the standard is definitely lower, but I think that is more due to the assumption that most of the time the item in question will be obsolete before it wears out anyway. Is it really worth building a computer to last 10 years when more than 95% of the people who buy it will replace it within 3 regardless of whether it still works? How many of those 95% would change their mind about the purchase if the item in question cost 15% more because the manufacturer decided to use higher quality parts. There are computers that are made to last that long - I have a 200 MHz Pentium Pro in the basement that still works - but you have to be willing to pay a premium for them.

In the end, consumer electronics are really not all that different than any other product - you get what you pay for. Making a product well costs money. If you buy a cheaply made product because you want to save a few bucks, that's your decision, but you shouldn't act surprised if it doesn't have the same life expectancy. The same is true in your example as well. If you had purchased a $50 Sanyo microwave from Bed Bath & Beyond five years ago, you probably wouldn't have gotten the same response.

Re:It probably won't last another 4 years

[BeerCat]

The Zune was in effect sold with a predictable and correctable flaw (leap years are very predictable), causing it fail out with normal wear and tear, which would class it as defective product.

In UK law at least this is a significant difference... you can never tell in the US though.

Perhaps the existing consumer protection legislation is one reason why it hasn't been sold in the UK?

Re:It probably won't last another 4 years

[Alex Belits]

Because software does not wear out?

Re:It probably won't last another 4 years

[Gr8Apes]

I hear you. My 1984 Sharp Carousel II Microwave is still alive and kicking just fine, although it is weaker (only 700W I think) than my 1200W new smaller microwave whose controls are much less intuitive than the Sharps. I much prefer the old simpler controls.

Re:It probably won't last another 4 years

[alvinrod]

I think that at least part of the reason we collectively accept this has a lot to do with the idea that these devices are generally obsolete are at least significantly out of date after five years. If refrigerators and bicycles were making the same kind of advances as these other products, most people honestly wouldn't care if they junked out in five years. If your fridge was doubling in performance every 18 months, wouldn't you want to get a new one every six years or so to take advantage of the cost savings?

We're already starting to reach a point where the common user probably isn't putting their system to full use. In another few years, the baseline desktop models will probably have more than enough computational power to satisfy non-power users. Businesses running computationally heavy software will still need more power, but mom and pop won't even be able to scratch the surface of their eight core, eight gig RAM system with just office apps and email. At that point I can see people buying a desktop with the intention that it last for ten years or more.

Of course this just shifts the battlefield to the netbook and cell phone segment where the performance gains are going to be more significant. Eventually the hardware will peak in this area as well and once again the market will find some new segment to rush after; probably some guy who figures out how to cram all of that functionality into a watch capable of projecting a 3D holograph which is used for a display. Then that'll be the new craze as no one really needs to upgrade their netbook to the new 32 core model with 16 TB of storage space.

When the pace of technology is moving so fast that something becomes obsolete after five years anyhow, most people won't really care if it doesn't last much longer. A few might, but they're probably not in the majority. Add in our societies tendency to go after the product with the least cost upfront (regardless of whether or not it's a POS that will have to be replaced soon after purchase.) and that we're so willing to purchase replacements is it really any surprise the businesses have reacted to what the market seems to demand?

Re:It probably won't last another 4 years

[Tycho]

The OBD (OnBoard Diagnostics) system on my 1996 Honda Odyssey "Minivan" had its "Engine Misfire" sensor intentionally disabled, which caused the emissions released to violate EPA standards. The EPA sued Honda, and both came to an agreement that gave owners free replacement of the defective components under a "warranty extension". The lawsuit was settled back in 1998, however. Seriously, did you think the same thing would have happened at any time recently under Cheney err, W?

Then there is also the Apple Powerbook 5300 series that had a seven year "warranty extension". The 5300 series were awful, in both quality, durability, and performance. If you didn't get one of the first laptops in the 5300 series, you missed out on the self-igniting Lithium-ion batteries. Later 5300 series owners, still had to deal with power jacks that liked to fail by separating from the motherboard or the magic screen hinges that could close unexpectedly on one's hand at any moment, among other problems. On other machines from 1995 and 1996, Apple had "warranty extensions" to fix problems that impaired the computer's use, but that were not of any danger or that affected actual functionality.

While this Zune problem is serious, a patch should be issued if possible, or a free replacement/upgrade program should be offered to owners.

Disclosure: I do not own a Zune of the model in question, much less any Zune. I own a 60GB 5G iPod, the only Turing-complete Apple branded device I own. I would hope that Apple would do the same if such a flaw was present in my iPod even at this date.

Re:It probably won't last another 4 years

[ta bu shi da yu]

I have a better FAQ - see my blog. Crap code on a monumental scale!

Re:It probably won't last another 4 years

[jkgamer]

However,
      If you purchase a piece of hardware that cleary has a defective design, (i.e. the fuel tanks on the Ford Pinto, an Xbox 360 that doesn't properly disperse heat causing it to die prematurely with the red ring of death) you could and should expect the manufacturer to correct the situation. Just because the inability to play back music on my Zune isn't life threatening doesn't make it OK for merchants to pawn defective equipment off onto an unsuspecting public. Furthermore, this is a defect that has ALWAYS been there, just not discovered until now. It is not a part that wore out over time. The Zune was defective from day one. This assumes that the bug was present in earlier versions of the firmware. If it was not, then does that mean that Ford can come 'force' me to upgrade my pickup with a part that will soon render it unusable? This is essentially what Microsoft does in order for you to make use of their online DRM protected music distribution. Microsoft was just lucky in that it only caused a temporary single day incapacitation of their product. What kind of outrage would there have been if this had turned out to be a permanent 'Zunicide'?

Re:It probably won't last another 4 years

[petermgreen]

but mom and pop won't even be able to scratch the surface of their eight core, eight gig RAM system with just office apps and email
Never underestimate the power of bloatware..........

Re:It probably won't last another 4 years

[uniquegeek]

I would make the argument buffer overflows or memory leaks are software's equivalent of "wearing out" (in an ungraceful/unnecessary manner). Kinda of like using very cheap thread to stitch a t-shirt.

Re:It probably won't last another 4 years

[Anonymous Coward]

No, it's not even close.

code (i.e. electronic bits) != cloth.

Mind you I have yet to think up an acceptable "real world" analogy, but thread and buffer overflows?!

Just a thought...

A.A.M

Re:It probably won't last another 4 years

[gparent]

No, I meant the Microsoft-released FAQ which explains that they will issue a Firmware fix in order for the bug not to reappear on 2012. Your blog has nothing to do with it.

Re:It probably won't last another 4 years

[uniquegeek]

I would hope with environmentalism being pushed as the trendy thing to do that concepts such as Reware will become more mainstream. We really have more money than we know what to do with.
We really should do this for better reasons (i.e. other than it being trendy), but whatever gets the ball rolling...
http://dev.eyebeam.org/projects/reware/wiki/Reware
How cool would it be to donate old devices to schools and lets students tinker around with them?

Re:It probably won't last another 4 years

[jc42]

It ought to simply be

while (days > daysInYear(year))
{
days -= daysInYear(year);
year += 1;
}

Hey, c'mon now; programmers are almost universally judged by their bosses by the number of lines of code they produce. The (buggy) MS code used 16 lines to do what you did in 5 lines. Therefore, the original (buggy) code is considered more than 3 times better than yours. No programmer interested in a good professional career would write code so simply and obviously correct.

This isn't really a joke. One a project a few years ago, I fixed several bugs by doing rewrites like yours, resulting in fewer lines of code. My record actually had a note indicating that I had negative productivity during that period, and my superiors had a real problem giving me a good review because of it.

Yes, I did find another job soon thereafter. But that wasn't the last time something like that happened.

(And I would probably save the first call of daysInYear(year) in a local variable, which would make the code a bit faster. But I could declare the local on a separate line, incrementing the line count, so it would look good to the line counters. ;-)

Re:It probably won't last another 4 years

[Anonymous Coward]

I saved $1 a month in power for many years

If that kind of "money" matters to you, get a better job.

Re:It probably won't last another 4 years

[nizo]

That's ok; since I am an American you could have used grams of fairy dust and it would have meant as much to me as pounds and pence.

Re:It probably won't last another 4 years

[nizo]

How about 5 lines of code plus twenty lines of comments explaining why the previous coder was an idiot?

Re:It probably won't last another 4 years

[magarity]

And looking at line 59 you can see that there is planned obsolescence(!) for the year 2080. Zune owners should demand a refund
 
Wow, that beats my Timex DataBank 20 watch. Its year date range only goes through 2016. In 7 years I'll let you know if Timex gets me a firmware fix when I call to complain.

Re:It probably won't last another 4 years

[jc42]

Nah; most code-size measurements exclude comments, on the grounds that comments aren't executed by the computer, and thus aren't code. This puts subtle pressure on the programmers to not write comments, since this just takes time that leads to being behind schedule.

It's hard to imagine any rating system that's more screwed up than the system used in most companies to rate the output of their programmers. If they were consciously trying to sabotage the software, they probably wouldn't come up with any schemes nearly as effective as judging programmers by lines of code produced.

Re:It probably won't last another 4 years

[ta bu shi da yu]

Try to be more clear in future. You did say "they have a detailed FAQ which explains the issue in detail", and they have explained how to "fix it". And in four years time, none of those Zunes will be operational I suspect.

Re:It probably won't last another 4 years

[Anonymous Coward]

Suppose instead of this being Zune's firmware it was a microwave you bought 5 years ago. Would you have any claim to have it fixed (out of warranty, etc).

I had an expensive ($250) over-range microwave that would not function at all until the date and time were entered. Now, you could enter any time/date but it was very annoying when the power went out (stupid clock reprogramming procedure) or the clock was otherwise out of sync. I'd prefer no clock (flashing 12:00 wouldn't work). My advice is to not buy an expensive microwave (with a 2 hour installation procedure) without first having it plugged in and run before your eyes. If they balk, walk to electrical and grab a $4 electrical cord. Open cord and take to appliances. What would happen if the date change brought up an expected error? Beats me but I wouldn't count on the dipshits that programmed it to fix it.

Re:It probably won't last another 4 years

[Paradise Pete]

(And I would probably save the first call of daysInYear(year) in a local variable, which would make the code a bit faster.

Probably so, and I thought about it, but the calculation for daysInYear is pretty darn fast. Plus if this is going to burned into ROM then maybe smaller is better in this case. And "premature optimization" and all that....besides, it looks better this way :-)

Re:It probably won't last another 4 years

[Anonymous Coward]

FailsForSure?

Re:It probably won't last another 4 years

[b4dc0d3r]

Technology moves so quickly that for a lot of people 1 year or 3 years is more than enough time. If it breaks you get to upgrade. Also, it's hard to find a competing product with a longer warranty so the manufacturers don't/can't get the feedback.

I think people are more willing to spend money separately, and also looking for lower prices. So a $100 product looks more attractive when you take off $10 sold as the store's "replacement program" and make a $90 product with less warranty. Then the $90 product looks like a better deal without the in-store warranty alongside the "I'll upgrade when it breaks" idea.

Re:It probably won't last another 4 years

[Anonymous Coward]

The (buggy) MS code used 16 lines to do what you did in 5 lines.

[nitpick]Except he didn't exactly do it 5 lines because there is no existing daysInYear() function.[/nitpick]

Then again, no need to create one.

daysInYear = (isLeapYear(year) ? 366 : 365);

while (days > daysInYear)
{
days -= daysInYear;
year += 1;
daysInYear = (isLeapYear(year) ? 366 : 365);
}

There, 8 lines. Still half of the original code, though that can probably be reduced due to the duplicate line.

Re:It probably won't last another 4 years

[isaac338]

Let's talk about items costing less than a laptop, so less than 2000.

Where were you able to buy a home furnace that cost you less than 2000?

What ever happened to the dollar sign? Am I just meant to infer that you're talking about dollars because of the context? Why is it so hard to type $2000 instead of 2000?

I try to not grammar nazi too much but this kind of thing just irks me - having to read a sentence twice while skimming to figure out that you're not referring to a year or a quantity of some other sort seems silly to me.

Re:It probably won't last another 4 years

[gparent]

Try to be more clear in future. You did say "they have a detailed FAQ which explains the issue in detail", and they have explained how to "fix it". And in four years time, none of those Zunes will be operational I suspect.

I know I wasn't clear, but if you knew anything about the Zune issue, you'd be aware that they have a FAQ which states very clearly that they are releasing a firmware update to fix it.

Re:It probably won't last another 4 years

[RiotingPacifist]

i see why youve been moded funny, but when faced with this bug microsoft had 3 options
1) call everybody back to work new years eve and rush out a fix that may cause problems elsewhere
2) wait till the new year and fix at a reasonable speed so the the fix doenst introduce new bugs
3) wait till 4 years time and ignore the 2 remaining zune 30 users

I would never choose 1, its simply not worth the hastle.
This leaves 2 & 3, while 2 may save some face, the fact is it will only keep 2 people more happy than if they choose 3 but will cost them money, so is not worth it.
Given that 99.93% uptime is pretty good for Microsoft code, the obvious choice is 3.

Re:It probably won't last another 4 years

[fishbowl]

>If my microwave had a defective gear in the motor that spins the turny-thing (technical term) that broke after warranty, I
>wouldn't expect it to be fixed. Is a defective line of code somewhere really all that different?

If the "turny-thing" failed from the first time you tried to use it, I think you'd want to return it. What does a warranty have to do with it?

Re:It probably won't last another 4 years

[sowth]

If I bought a microwave and it did that, I would probably never buy from the manufacturer again. Maybe if they apoligized for making such a crappy product and it was shown they now don't make defective products anymore. Though even then, if it was the exact same product as another mfg with the same chance for defects and such, I would buy the other guy's product.

Your bar is too low. If you bought it as a charity case or because you want to help out local / new businesses I could understand, but putting up with defective products just because you are too lazy is idiotic. You have to be demanding or the manufacturers will keep putting out crap, and the crappier they are, the more it wastes your time and money in the long run. So if you are lazy, be lazy later rather than now.

Re:It probably won't last another 4 years

[azenpunk]

the defective line of code was broken before the warranty expired.

Re:It probably won't last another 4 years

[beatle11]

Well at this point it doesn't matter anymore so I guess it is acceptable. It should never have happened in the first place though.

Re:It probably won't last another 4 years

[azenpunk]

a gram of fairy dust costs way more than just a pound sterling.

Re:It probably won't last another 4 years

[MaskedSlacker]

Did you advocate being so lazy as to procrastinate procrastination itself? This meta-laziness shall not be condoned!

Re:It probably won't last another 4 years

[MaskedSlacker]

Wouldn't your iPod have to have infinite memory to be Turing-complete?

Re:It probably won't last another 4 years

[uniquegeek]

Things wear out because of shoddy materials and/or shoddy workmanship. This is possible with programmers and their environment. Is that more clear? Analogies need not be almost identical to the point in order to prove it.

Re:It probably won't last another 4 years

[ta bu shi da yu]

I don't own a Zune, and probably never will. What I did find was the sourcecode on Pastie, so I commented on it to explain why the problem occured. That was the frequently asked question: why did it occur? And I have explained why it occured.

Good to see they are releasing a firmware update.

Re:It probably won't last another 4 years

[adamofgreyskull]

1 GBP in USD = 1.4456
1 USD in grams of fairy dust = ?

All "Whoosh" aside, that's about 19 cents.

Re:It probably won't last another 4 years

[thetoadwarrior]

Or worse yet in order to use the software you have to accept their terms. But to read the terms you have to open the product. If you open the product, disgree and try to return it you're called a thief and have to go through a hassle to get a refund.

It's in no way consumer friendly so most people won't disagree with their terms evne if they have the time to read 50 paragraphs of unnecessary BS which basically say you have no rights and they've done nothing wrong so they don't have to do a good job.

As it's been mentioned already most people will accept this because the bar has been set so low it doesn't take much to make people think they're getting a good deal.

It would be nice if people would actually stick together and push for something to be done about this but I don't see that happening any time soon.

Re:It probably won't last another 4 years

[Steve001]

Paradise Pete wrote:

The Zune was in effect sold with a predictable and correctable flaw

And if you look at the bug in the code (line 259) it's atrocious. Something a junior programmer would be embarrassed about.

When days is 366 it causes an infinite loop. And also note that simply changing line 263 to use 365 causes a different bug. So the whole approach is wrong. It ought to simply be

while (days > daysInYear(year))
{
days -= daysInYear(year);
year += 1;
}

I'm not a C programmer, but why not do the following (in basic, I'm sure it could be easily translated into C):

• 10 if days = 366 then years = years + 1
• 20 if years = 2100 then goto 70
• 30 if years = 2200 then goto 70
• 40 if years = 2300 then goto 70
• 50 if (years/4)*4 = int(years) then days = 0
• 60 goto 80
• 70 days = 1
• 80 end

I'm sure lines 20 through 40 could be compressed into a single line to accomodate the century years.

Re:It probably won't last another 4 years

[Paradise Pete]

Well, line 10 is wrong. Day 366 should not change the year for leap years. Also, days is the number of days since 1980, and you're not dealing with that. What you have to do is walk forward through the years so that you land on the proper year and day.

Re:It probably won't last another 4 years

[Paradise Pete]

]Except he didn't exactly do it 5 lines because there is no existing daysInYear() function.

The presumption was that it would replace the now superfluous isLeapYear function.

Re:It probably won't last another 4 years

[MikeBabcock]

Have you checked for escaping microwave radiation lately? Just curious :)

Re:It probably won't last another 4 years

[cbhacking]

That's OK, another solution would be to simply add a
else
{
        break;
}
between lines 267 and 268. Of course, it's a slightly unintuitive approach to otherwise nicely self-documenting code, so a comment would make sense there too. In any case, it's at least four extra lines (using the same style as the rest of the code that I saw, no less)...

Re:It probably won't last another 4 years

[Steve001]

Paradise Pete wrote:

Well, line 10 is wrong. Day 366 should not change the year for leap years. Also, days is the number of days since 1980, and you're not dealing with that. What you have to do is walk forward through the years so that you land on the proper year and day.

Sorry for being unclear. I was using "days" as a variable to mean basically the julian date (resetting it to "0" on the first day of each year), not the total number of days since a specific year. In the same way, I was thinking of "years" as a separate variable indicating the current year.

To clarify, essentially leap years would start on day 0, non-leap years would start on day 1, each year would end on day 365, and on 1 Jan the calendar would show day 366 which would then prompt the system to change the year and then set the day to 1 or 0 (depending on whether the new year is a leap year or not).

Re:It probably won't last another 4 years

[sjames]

While any shop that would actually count removing unnecessary code AGAINST you is a great place to leave, you could always pad out the difference like:

i=1;
i=1; // do this a few times to make it stick!
i=1;
i=1;
i=1;
i=1;
i=1;
i=1;
i=1;
i=1; // we are now performance review compliant.

The best part is that any decent compiler will strip out those extra constant assignments for you so the end product doesn't suffer.

Re:It probably won't last another 4 years

[Sidzilla]

But your popcorn always burns.

Re:It probably won't last another 4 years

[Anonymous Coward]

If I bought a microwave and it did that, I would probably never buy from the manufacturer again.

Because clearly the Apple branded microwave that costs $600 plus $99 a month would heat his sandwich "snappier".

And when that one froze up or refused to heat sandwiches with cheese, it's because he didn't really want to heat that anyway.

Re:It probably won't last another 4 years

[KozmoKramer]

I know my IPOD probably WILL last another 4 years. But, yes kudos to you for making me laugh so hard my side hurts now! I hope you are happy with yourself funnyman! :)

Re:It probably won't last another 4 years

[Kimos]

It's sometimes sad how >15 yro devices outlive new products.

There. Fixed that for you.

I'm not your average joe MS basher

[bytesex]

But I've got to say: this is just typical.

Re:I'm not your average joe MS basher

[mike260]

I'm not your average joe MS basher

True enough; nowadays, the average Slashdot-dwelling MS basher will try to make some kind of reasoned, evidence-backed argument instead of just huffing loudly and saying "this is typical".

Re:I'm not your average joe MS basher

[AmberBlackCat]

[I'm not your average joe MS basher] But I've got to say: this is just typical.

That definitely sounds like the average Microsoft basher. I think I hate Microsoft more than most, and hate Zune as much as you. Even so, I just wish my iPod and Fedora installations would only fuck up one day out of every four years.

Most modern hardware/software bundles

[Finallyjoined!!!]

Have problems/bugs of some kind or other, but none quite as spectacularly "shoot yourself in the foot, with a 12 bore" headlines-wise as this little episode. :-)

Nice!

[whisper_jeff]

Nice! The best way to fix something is do nothing at all and hope it works next time. Well done!

Re:Nice!

[Anonymous Coward]

Isn't that reminiscent of Y2K?

I of course, was sitting in a server closet for a Power/Gas Utility during the Y2K rollover...nothing happened obviously.

Where were you, and what were you doing during the "End Of Times"?

Re:Nice!

[Anonymous Coward]

Nothing happened in Y2K because people spend a lot of time and a lot of effort to ensure that nothing happened.

Re:Nice!

[Kagura]

That's also why I spent a lot of time and effort preventing the alien invasion yesterday to ensure nothing happened.

Re:Nice!

[poopdeville]

You wrote code to prevent an alien invasion? Nice, can I have a patch?

Oh, you mean what you did wasn't verifiable, much unlike Y2K bug fixes. I see.

Testing!?!

[FranTaylor]

You would think that a company the size of Microsoft would have the resources to have a few Zunes in QA with their clocks set ahead. But hey, there were no lessons to be learned from Y2K, right?

Re:Testing!?!

[Anonymous Coward]

What's Y2K? Isn't it 1909 now....?

Re:Testing!?!

[Sancho]

Clocks set ahead? Leap year is a really well-known edge case. There's no acceptable reason that setting the date to the boundaries in a leap year (including February 29, and the day before, and the day after) shouldn't be part of the standard tests.

Re:Testing!?!

[dingen]

Clocks set ahead? Leap year is a really well-known edge case. There's no acceptable reason that setting the date to the boundaries in a leap year (including February 29, and the day before, and the day after) shouldn't be part of the standard tests.

Well, judging from the number of Zune owners who couldn't listen to music on new years eve, it probably should be.

Re:Testing!?!

[Sancho]

Yeah. If you re-read what I wrote, I said there's no good reason that it's not a part of the standard tests.

Re:Testing!?!

[RoboRay]

Well, judging from the number of Zune owners who couldn't listen to music on new years eve, it probably should be.

What, all three of them?

Re:Testing!?!

[dingen]

I don't like no double negatives.

Re:Testing!?!

[plopez]

You're assuming that MS has some sort of institutional competence.

Re:Testing!?!

[rcjhawk]

Actually, it's 19109

Re:Testing!?!

[Lars T.]

I don't see "setting the date to ... December 31st of a leap year" in your post. But then I don't see a good reason why that could possibly cause an almost-bricked device either.

Re:Testing!?!

[Anonymous Coward]

This is actually a very good example why testing isn't the road to great software: What are you going to test? The first and last days of a leap year? The 29th of February? The days before and after these dates? Starting up, shutting down, rolling into and out of all those dates? That's an awful lot of testing for something so benign, don't you think? If you test that much for a problem that has a well known implementation, the flood of tests for the more innovative functions of your product are going to delay the product until nobody cares anymore if it works or not.

This is a case of someone (badly) reinventing the wheel, with no second pair of eyes looking at the code before it goes into production. In other words, it's an organizational problem.

Re:Testing!?!

[Sancho]

I said "setting it to the boundaries." I explicitly included the February case because it's possibly a less obvious boundary.

The boundaries would obviously be Dec 31 on the previous year, Jan 1 on the leap year (though it's hard to envision code on which these would break, they should be tested), Dec 31 of the leap year, and Jan 1 of the next year.

In fact, it might even be reasonable to test the first and last day of every month of the leap year. Addition errors could occur at any point.

Re:Testing!?!

[Dragonslicer]

I'm more concerned about what kind of date calculation and/or storage these things are doing that would cause a hard freeze at the end of a leap year. It's not like there aren't already dozens of perfectly-working timekeeping systems out there.

Re:Testing!?!

[ian_from_brisbane]

Well, judging from the number of Zune owners who couldn't listen to music on new years eve, it probably should be.

I'm sure all 6 of them were probably too drunk to notice.

Re:Testing!?!

[Anonymous Coward]

>That's an awful lot of testing for something so benign, don't you think?

I think you wouldn't last very long where I work.

Re:Testing!?!

[Anonymous Coward]

You would perform 30 tests for one aspect of leap year support which is represented by less than 30 lines of code? Have you shipped a product yet? Look, I am certainly in favor of making sure that a function like that does what it's expected to do, but if that isn't done by the company supplying the code, then no reasonable amount of testing can find the bugs.

Cinderella

[Anonymous Coward]

If you think about it, Cinderella was just a piece of pro-DRM propaganda.

Oh shit, my Zune just turned into a pumpkin.

Sorry to gloat but

[Anonymous Coward]

My iPod, Macbook, iPhone, Time Capsule, Airport Express, and Apple TV are all working just fine!

Re:Sorry to gloat but

[Anonymous Coward]

Congrats on becoming a tool!

Re:Sorry to gloat but

[SamsLembas]

My Linux desktop, Linux server, Linksys Linux router, Actiontec Linux router, Sony-Ericsson cell phone, Linux-running Aspire One, PS3, digital watch, and pedal-powered bike are all working fine.

Re:Sorry to gloat but

[im_thatoneguy]

And my zune has been working for 2 days since you posted your gloat. What's your point?

This whole thing is retarded. I have an 'affected' Zune 30. "Oh no! I can't use my zune for 12 hours when I'm out celebrating once every 10 years! What ever will I do!"

Please. This is like the battery running out... only simultaneously around the world. What's the point of creating, testing and releasing a patch (Probably at least 12 hours) when the bug will have already been cleared by the time it's been released to consumers?

Like most people I slept in for the last 12 hours. Was out partying for the middle 6 and only was sitting by the computer for the first 6. It was a silly bug that only affected a small handful of people in no significant way. I have to take my car in for oil every few months and leave it in the shop for 24 hours! OH NO HORRIBLE CAR BUG THAT REQUIRES IT TO BE DOWN EVERY FEW MONTHS! I have to spend an hour every week cleaning my apartment which is more than 2 days of cleaning every year! Oh no! Horrible apartment bug!

So your zune didn't work for a couple of hours... who cares.

Re:Sorry to gloat but

[Anonymous Coward]

Oh no! I can't use my zune for 12 hours when I'm out celebrating once every 10 years! What ever will I do!

What planet are you on?

Re:Sorry to gloat but

[Anonymous Coward]

Well, my comment was meant to be a joke, like Nelson's "Ha ha" in the Simpsons is funny.

Still, it's just the latest fiasco by MS. They produce crap, and everyone eats it up.

Can anyone explain this bug?

[dingen]

What could it be that makes the device not boot on leapdays? I could understand if the date/time would be wrongly displayed or something, but not functioning at all? WTF?

Re:Can anyone explain this bug?

[sakdoctor]

if (year % 400 == 0) hard_crash()
  else if (year % 100 == 0) boot()
  else if (year % 4 == 0) hard_crash()
  else boot()

Re:Can anyone explain this bug?

[Anonymous Coward]

Here's the actual buggy code.
The error is infinite loop in ConvertDays(), starting at line 249. The first loop does not cope with "IsLeapYear() == true" when "days == 366"

Re:Can anyone explain this bug?

[slash.duncan]

I know nothing in particular about Zunes, but a shot in the dark (but based on some of the articles on the DRM tech in Vista I've read about) would be that it has to do with the DRM. The extra day in the year made the time count up further in the year than it expected, and it probably set off a tilt bit that caused it to think that someone was trying to hack it or something so it refused to run.

Maybe someone else with information to replace my frankly admitted speculation can confirm or deny...

Re:Can anyone explain this bug?

[Fusen]

while (days > 365)
    {
        if (IsLeapYear(year))
        {
            if (days > 366)
            {
                days -= 366;
                year += 1;
            }
        }
        else
        {
            days -= 365;
            year += 1;
        }
    }

source code that caused the bug.

Re:Can anyone explain this bug?

[Anonymous Coward]

See the AC above (and six minutes before) you: the bug was in a routine that breaks down a count of days into a days/months/years; it has absolutely nothing to with DRM.

Re:Can anyone explain this bug?

[Anonymous Coward]

In case you can't see how this fails: On December 31st in a leap year, days is counted down to 366 like it's supposed to, and then the IsLeapYear() test is true, but days>366 is not, so the loop body does nothing and the while becomes an infinite loop.

This code can not possibly have been accepted in any kind of code review. Someone would have pointed out that there are O(1) formulas for calendar calculations.

Re:Can anyone explain this bug?

[dmihalik]

The following information is from the analysis done at the Program Phases site.

Verbose Output of ConvertDays() function:
1980: 366 (10593 - 366 = 10227) years=1
1981: 365 (10227 - 365 = 9862) years=2
1982: 365 (9862 - 365 = 9497) years=3
1983: 365 (9497 - 365 = 9132) years=4
1984: 366 (9132 - 366 = 8766) years=5
1985: 365 (8766 - 365 = 8401) years=6
1986: 365 (8401 - 365 = 8036) years=7
1987: 365 (8036 - 365 = 7671) years=8
1988: 366 (7671 - 366 = 7305) years=9
1989: 365 (7305 - 365 = 6940) years=10
1990: 365 (6940 - 365 = 6575) years=11
1991: 365 (6575 - 365 = 6210) years=12
1992: 366 (6210 - 366 = 5845) years=13
1993: 365 (5844 - 365 = 5479) years=14
1994: 365 (5479 - 365 = 5114) years=15
1995: 365 (5114 - 365 = 4749) years=16
1996: 366 (4749 - 366 = 4383) years=17
1997: 365 (4383 - 365 = 4018) years=18
1998: 365 (4018 - 365 = 3653) years=19
1999: 365 (3653 - 365 = 3288) years=20
2000: 366 (3288 - 366 = 2922) years=21
2001: 365 (2922 - 365 = 2557) years=22
2002: 365 (2557 - 365 = 2192) years=23
2003: 365 (2192 - 365 = 1827) years=24
2004: 366 (1827 - 366 = 1461) years=25
2005: 365 (1461 - 365 = 1096) years=26
2006: 365 (1096 - 365 = 731) years=27
2007: 365 (731 - 365 = 366) years=28 - causes infinite loop
2008: 366 (366 - 366 = 0) -- On last day of leap year, program execution never gets here.

On December 31st 2008, IsLeapyear(2008) is true and days equals 366. If IsLeapYear(2008) is true and days is not greater than 366, the number of days never decrements again resulting in days never becoming less than 366. If the days never becomes less than 366, the infinite looping results.

Re:Can anyone explain this bug?

[MattCohn.com]

Here's the actual buggy code.
The error is infinite loop in ConvertDays(), starting at line 249. The first loop does not cope with "IsLeapYear() == true" when "days == 366"

The fix:

        year = ORIGINYEAR;

        daysInYear = IsLeapYear(year) ? 366 : 365;
        while (days > daysInYear)
        {
                days -= daysInYear;
                year += 1;

                daysInYear = IsLeapYear(year) ? 366 : 365;
        }

Re:Can anyone explain this bug?

[lucifuge31337]

...and a perfect example of why testers should be working closely with programmers, writing sensible unit tests as the code progresses.

Re:Can anyone explain this bug?

[sjelkjd]

It will enter an infinite loop if days == 366 and IsLeapYear is true.

Re:Can anyone explain this bug?

[drosboro]

This is a problem I've given my grade 12 computing class in the past. The quality of code in the linked file is pretty comparable to what I've seen submitted.

Seriously, the IsLeapYear() function is 13 lines long, and is no more readable than, say,

int IsLeapYear(int Year) {
    return (((Year % 4) == 0) && (((Year % 100) > 0) || ((Year % 400) == 0)));
}

It looks to me like the ConvertDays() function was written by the same (amateurish) coder. Other bits of the source aren't nearly so bad.

Re:Can anyone explain this bug?

[UnknowingFool]

The error is infinite loop . . .

Typical MS. They're copying Apple again but this time too literally. :P

Re:Can anyone explain this bug?

[Kagura]

Here's the actual buggy code. The error is infinite loop in ConvertDays(), starting at line 249. The first loop does not cope with "IsLeapYear() == true" when "days == 366"

Wow, that was pretty cool. Thank you.

Re:Can anyone explain this bug?

[UnknowingFool]

Someone would have pointed out that there are O(1) formulas for calendar calculations.

For that to happen, MS would have to follow standards. You know where this discussion will go.

Re:Can anyone explain this bug?

[volxdragon]

When days == 366 and IsLeapYear() evaluates to true, you loop forever on the while because you never decrement days internally to the loop under that exact condition.

Re:Can anyone explain this bug?

[judododo]

If my understanding is correct, ConvertDays looks like it never returns FALSE either. This might not lead to an other bug but it shows the quality of the code.

Re:Can anyone explain this bug?

[Anonymous Coward]

Of course, the fix so that this doesn't happen again in 2012 and so on will probably be a 50MB patch.

Re:Can anyone explain this bug?

[Lars T.]

See the AC above (and six minutes before) you: the bug was in a routine that breaks down a count of days into a days/months/years; it has absolutely nothing to with DRM.

So it wasn't in a new, extremely complicated code written to hide something, but in code that has been implemented thousands of times flawlessly (and more efficient) before - gee, that's a relief.

Re:Can anyone explain this bug?

[JackHoffman]

That is deeply flawed code. (Why? Left as an exercise to the reader.)

The correct solution, if you want to keep the looping algorithm, is to add "else break;" as the alternate case of the "if (days > 366)" test: The infinite loop case then terminates the loop with the right year and days=366, which is the expected result.

Re:Can anyone explain this bug?

[aLEczapKA]

how the heck, this is supposed to work:

        if (days > 366)

when it's

        while (days > 365)

above? :o

Re:Can anyone explain this bug?

[Linker3000]

So, what we're saying is that Microsoft will ask the appropriate official bodies to redefine core standards so that every manufacturer of processor-based equipment has to ensure their kit runs in an infinite loop on 31st Dec in leap years to conform with Microsoft's operating model?

Re:Can anyone explain this bug?

[DannyO152]

I have to wonder about calling isLeapYear(year) every single time when if the last year was a leap year you have three guaranteed non-leap years and a leap year except for 3 years out of every 400.

Soooo. If this is the code and the flaw, why were only 30 GB Firmware 3.x Zunes affected?

Re:Can anyone explain this bug?

[JackHoffman]

The function iteratively converts days into years. If there are more days left in the days variable than there are days in a year (365), then the days in that year are subtracted from the days variable and added as 1 year to the year variable.

It starts with year=1980, because the RTC counts days since 1/1/1980 (inclusive). For normal years, it subtracts 365 days and adds a year. After the first iteration, year is 1981 and days is the number of days since 1/1/1981 (inclusive). If the loop is currently looking at a leap year, then 366 days are subtracted from the days variable and 1 year is added to the year variable. So far the code looks like this:

while (days>365){
    if (IsLeapYear(year)){
        days-=366;
        year+=1;
    }else{
        days-=365;
        year+=1;
    }
}

The crazy thing is that someone must have looked at the edge case in that code: The last day of a leap year. On that day, the above code fails by incrementing year once too often, because at the beginning of the last iteration, the loop test indicates that there are more days in the days variable than there are in a year, but there are not, because a leap year has 366 days. That edge case is caught by the second if:

while (days>365){
    if (IsLeapYear(year)){
        if (days>366){
            days-=366;
            year+=1;
        }
    }else{
        days-=365;
        year+=1;
    }
}

The loop goes into the last iteration because of the loop condition which is on day short, then the IsLeapYear test selects the first branch, and instead of blindly incrementing the year and subtracting 366 days, there is an extra check if there are really more days left to make a full year...and then it fails to handle the only case where the code fails without that extra check. It should simply break the loop:

while (days>365){
    if (IsLeapYear(year)){
        if (days>366){
            days-=366;
        }else{
            break; // days==366 && IsLeapYear(year): end of calculation
        }
    }else{
        days-=365;
    }
    year+=1;
}

(Matt's code always reduces the day count by 366. 1980 was a leap year.)

Re:Can anyone explain this bug?

[JackHoffman]

Sorry, I overlooked the second daysInYear assignment. That code would actually work, but because of the unexpected code duplication, I would have written it like this:

year = ORIGINYEAR;

while (true) {
        daysInYear = IsLeapYear(year) ? 366 : 365;
        if (days <= daysInYear) break;
        days -= daysInYear;
        year += 1;
}

Re:Can anyone explain this bug?

[Gnavpot]

Was this a contest of making the code as complicated as possible? And it would be even more complicated if the missing line was added.

To a hobby programmer like me, it seems that this code could be simplified considerably:

daysOfYear = 365 + IsLeapYear(year);
while (days > daysOfYear )
        {
                                days -= daysOfYear;
                                year += 1;
                                daysOfYear = 365 + IsLeapYear(year);
        }

Re:Can anyone explain this bug?

[Anonymous Coward]

That is deeply flawed code. (Why? Left as an exercise to the reader.)

I'd say it ought to be left as an exercise for you. The code functions properly. He recalculates daysInYear each time.

Re:Can anyone explain this bug?

[Anonymous Coward]

This isn't microsoft's code at all. This is freescale at work. Ever wonder why they seem to be doing nohting... well, because they turn out shit like this when they do.

Re:Can anyone explain this bug?

[MattCohn.com]

Using the break statement violates structured programming. I feel maintaining structured code without gotos, breaks, and continues everywhere is worth making an effort.

Re:Can anyone explain this bug?

[Anonymous Coward]

And, even more readable:

return Year % 100 ? Year % 400 == 0 : Year % 4 == 0;

I hate superfluous parenthesis as well. return does not need have parenthesis around its value (return is a keyword, not a function).

Re:Can anyone explain this bug?

[Ecuador]

(Matt's code always reduces the day count by 366. 1980 was a leap year.)

I see that daysInYear is recalculated at the end of each iteration. What is your problem with that?

Moreover, counting years must be a "CS 101 introduction to Jave" level problem. Why are we analyzing this? Look at the MS code, laugh at the programmer and their code review practices and move on!

Re:Can anyone explain this bug?

[rk]

IsLeapYear could be implemented as a macro, if you feel function calls are too expensive:

#define IsLeapYear(x) x%4 ? 0 : (x%100 ? 1 : (x%400 ? 0:1))

Or, if your compiler supports declaring inline functions, you could (and probably should) go that way.

Re:Can anyone explain this bug?

[Anonymous Coward]

The while (true) loop is bad, bad practice.

I have been coding for twenty-two years. Trust me on this, my friend.

Re:Can anyone explain this bug?

[FloydTheDroid]

Most people would've just used the date library included with the language they're using. Apparently that wasn't an option here so it looks like this was a hearty helping of copy pasta with a small modification for leap years. Interesting that if they had left the check for days > 366 out it would have worked and looked so much more symmetrical too.

Personally I've written so many infinite loops that I don't even use "while" anymore unless I write unit tests which walk though every branch.

Re:Can anyone explain this bug?

[Anonymous Coward]

Why are we analyzing this? Look at the MS code

*Freescale code

Re:Can anyone explain this bug?

[fishbowl]

I guess the buggy code is O(n) since it is sensitive to input data that it will
never receive in practice, so that's sort of irrelevant.
The thing that jumps out at me is the use of "while" instead of "if", because
it shows the programmer is not quite sure whether there will ever be a 367th
day, or worse, that there ever will be more than "366 days". Somebody thinks he
is doing the right thing by being overly cautious, but while thinking about what
would happen if this routine got "days" as some big number, he should have noticed
the bug too.

This is not a good place to be hiding a problem like that -- if some other bug was
making the year into some incorrect value, the greedy nature of this loop would hide
it, and maybe you'd see it as some kind of "flashes January 1" error that is fixed on
reboot.

Maybe there's a patent on correct date routines and MS knows it :-)

Re:Can anyone explain this bug?

[Anonymous Coward]

This is reference code for the freescale chip the Zune 30 uses. The gigabeat uses the same chip and reference code which is why it is also affected. How do you think the code became available so quickly (or at all)?

You could make the argument that MS should have reviewed the reference code, but I doubt you care. It sounds like you're more interested in bashing teh M$.

Re:Can anyone explain this bug?

[shutdown -p now]

For that to happen, MS would have to follow standards. You know where this discussion will go.

The offending code wasn't written by Microsoft. It was in a driver written by Freescale, which provides the hardware MS uses in Zune.

The fault of MS in this case is that they didn't do proper QA, not that they wrote this (clearly moronic) code.

By the way, what does it have to do with "following standards"? We're talking about algorithms here, not representations. If someone writes a bubble sort in production code, it's stupid beyond measure, but it's not "non-standard" (because there's no standard).

Re:Can anyone explain this bug?

[Anonymous Coward]

Take another look at how that routine is supposed to work. For every year after 1980, it makes one run through the loop body, eating days to turn them into years. The programmer could just as well have caught the edge case with a days!=366 comparison, but the >366 comparison makes more sense because it expresses what is being tested for: Are there more days left than I can fit into this leap year? The mistake which leads to the infinite loop is that the edge case is excluded from the normal calculation, but is never handled itself.

Re:Can anyone explain this bug?

[Anonymous Coward]

I think it depends. This is a very short loop and strictly adhering to structured programming principles causes code duplication, which, to make matters worse, in this case duplicates two constants.

This:

preparation
while (test) {
    work
    preparation
}

can idiomatically be transformed into this:

while (true) {
    preparation
    if (!test) break;
    work
}

Pros:
- no code duplication
- order of preparation and work in the code logically correct

Cons:
- structured programming violation ("goto")
- loop condition not obvious

Re:Can anyone explain this bug?

[remmelt]

I really don't understand who their unit tests didn't catch this one.

Assumptions:
- they have unit tests
- there was a unit test written for this code
- the test covered the edge case of the leap year
- the test was run

Re:Can anyone explain this bug?

[Anonymous Coward]

Why is this being done with a loop in the first place?

Re:Can anyone explain this bug?

[cbhacking]

From what I heard, it wasn't actually only the Zunes with 3.0 firmware that failed to boot, although I didn't check that closely. In any case, the bug is in the driver for a component which the Zune 30 (and Toshiba Gigabeat S, which the 30 was based on and which also wouldn't boot) has, but none of the 2nd-gen or 3rd-gen Zunes have (all of which were designed in-house from the ground up).

Re:Can anyone explain this bug?

[Anonymous Coward]

This code can not possibly have been accepted in any kind of code review. Someone would have pointed out that there are O(1) formulas for calendar calculations.

Yeah, because it is very important that the date calculation is super fast in the year 2000000.

Optimizing that algorithm is a complete waste of time.

Re:Can anyone explain this bug?

[fishbowl]

I see that now, thanks.
I'm the type of programmer that looks for numerical solutions to things done with loops. Faced with this problem, I'm pretty sure this is the very last approach I'd take. But then, I haven't done any kind of date code aside from ctime conversion and (lots of) formatting, since about 1980, and I don't have the slightest clue about the Zune environment or what kind of limitations the programmer was up against. The risk of bad Karma precludes me making any remarks on whether or how this should have been tested. I'm not too proud to admit that sillier bugs have left with my signature, and I have respected colleagues who would admit the same.

I won't even comment on the fact that this was an open source project, where the "many eyes" could have seen it coming all the way across the bazaar.

Re:Can anyone explain this bug?

[QuietObserver]

That's what I wondered myself. Any halfassed programmer (such as myself) can easily see that the while () loop should have been a simple if () comparison.

Leap Year??

[Anonymous Coward]

Wasn't it a leap second?

Isn't this post a dupe?

[arover]

I thought we had gone over this whole "fix" of Microsoft's a few days ago? If anything, the OP should've focused the article more on its effect on the Toshiba model, because that's more recent news to me. Anyways, I doubt Microsoft is going to do anything else about this issue. The average consumer is willing to put up with a lot, especially if it happens once every few years, and, even then, doesn't give the user THAT much hassle. Plus, this IS Microsoft we're talking about. They have enough trouble fixing their larger hardware/software malfunctions, on products that sell better, let alone tending to things with which they hold a rather small market share for.

The Source Code

[linumax]

Here is source of the trouble.

Re:The Source Code

[neonux]

More precisely the bug is an infinite loop in ConvertDays function starting line 249 :

      while (days > 365)
        {
                if (IsLeapYear(year))
                {
                        if (days > 366)
                        {

When it is the 366th day of a leap year process is trapped in the while loop.

And well I suspect the while-based implementation is quite dumb in the first place...

Re:The Source Code

[Aladrin]

10 points for looking correct, but minus several million for not being correct.

Earlier in 2008, the bug did not exist. In the newest firmware, it does. that means the bug was introduced in 2008.

The copyright on that code ended in 2007, so the code hasn't been edited since then.

Clearly, this is not the code you are looking for.

Re:The Source Code

[slugtastic]

But 2008 wasn't a leap year...

Re:The Source Code

[Anonymous Coward]

But 2008 wasn't a leap year...

Oh?!?

Re:The Source Code

[slugtastic]

It's possible I was just too wasted to remember the 366'th day... I should check on the calendar.

Re:The Source Code

[wvmarle]

Look through the function starting at line 249: this causes the infinite loop.

Assuming proper code management and version control they will probably branch off a release sometime for release in 2007, and in the meantime continue writing the next version, which may have been mostly finished in 2007 already but maybe only pass quality control in 2008 for release then.

And this piece of code had not been tested/reviewed properly apparently.

Re:The Source Code

[Anonymous Coward]

Or the code was updated but not the copyright...

Re:The Source Code

[Anonymous Coward]

I found the actual problem. From the source:

if (pTime == NULL) goto cleanUp;

THEY USED GOTO?!

Re:The Source Code

[Blakey Rat]

Ok, it's been posted on every website and every forum about this issue on the entire Internet...

Is there any verification at all that this is actually the buggy code? Or did someone just pull it out of their ass? (I mean, obviously this code has the same bug, but is it the same code the Zune uses?)

Re:The Source Code

[ndtechnologies]

So both Microsoft and Toshiba purposely destroyed their firmware?

Re:The Source Code

[fm6]

I did a little googling and came up with this post, which claims that the code comes from the Freescale web site. Also a more informative explanation of the bug for those of us not up to analyzing all that C code.

There are two things that have me scratching my head.

First, doesn't anybody at Toshiba or MS do code reviews?

Second, doesn't Windows CE have libraries for converting from one date type to another? Is it not practical to use them in drivers? Or did somebody hand-code this conversion because they couldn't be bothered to look up the API?

Re:The Source Code

[Malevolyn]

Perhaps it was a quantum leap year and the extra day never really existed, but took play anyway? Or perhaps you just had to get wasted to leap.

Re:The Source Code

[Malevolyn]

Dammit, took PLACE.

Re:The Source Code

[Paradise Pete]

It's possible I was just too wasted to remember the 366'th day... I should check on the calendar.

If you need to look at a calendar to figure out if it's a leap year then maybe you should cut *way* back. (hint: evenly divisible by four is a good enough approximation, as it will be accurate for the rest of your life.)

Re:The Source Code

[vyrus128]

For anyone who's too lazy to search for it, the specific issue is on lines 259-274. (That would of course be in the "loop forever on leap day" function. ;-)

Re:The Source Code

[jez9999]

The copyright on that code ended in 2007, so the code hasn't been edited since then.

Copyright doesn't 'end'. It's somewhat erroneous even to put a 'until' year into a copyrighted work; just put the start year.

Cause of the Zune crash? Third party drivers

[Anonymous Coward]

A quote from the ZuneBoards forum:

After doing some poking around in the source code for the Zune's clock driver (available free from the Freescale website), I found the root cause of the now-infamous Zune 30 leapyear issue that struck everyone on New Year's Eve.

The Zune's real-time clock stores the time in terms of days and seconds since January 1st, 1980. When the Zune's clock is accessed, the driver turns the number of days into years/months/days and the number of seconds into hours/minutes/seconds. Likewise, when the clock is set, the driver does the opposite.

The Zune frontend first accesses the clock toward the end of the boot sequence. Doing this triggers the code that reads the clock and converts it to a date and time. Below is the part of this code that determines the year component of the date:

Code:

year = ORIGINYEAR; /* = 1980 */
 
while (days > 365)
{
    if (IsLeapYear(year))
    {
        if (days > 366)
        {
            days -= 366;
            year += 1;
        }
    }
    else
    {
        days -= 365;
        year += 1;
    }
}

Under normal circumstances, this works just fine. The function keeps subtracting either 365 or 366 until it gets down to less than a year's worth of days, which it then turns into the month and day of month. Thing is, in the case of the last day of a leap year, it keeps going until it hits 366. Thanks to the if (days > 366), it stops subtracting anything if the loop happens to be on a leap year. But 366 is too large to break out of the main loop, meaning that the Zune keeps looping forever and doesn't do anything else.

The unfortunate part is that there isn't anything that can be done to fix this besides somehow changing what the clock is set to (which is exactly what the battery disconnection trick ends up doing). On the other hand, it shows that Microsoft is correct: tomorrow, everyone's Zunes will operate normally again. However, if Microsoft doesn't fix this part of the firmware, the whole thing will happen all over again in 4 more years.. Hopefully by then a fix will be in place.

http://www.zuneboards.com/forums/zune-news/38143-cause-zune-30-leapyear-problem-isolated.html

In 4 years?

[fluch]

In 4 years, is there still a Zune around??

Re:In 4 years?

[Anonymous Coward]

In 4 years, will Microsoft still be around? /duck

Re:In 4 years?

[slugtastic]

In 4 years, will the Earth still be around? /popcorn

Re:In 4 years?

[Anonymous Coward]

In 4 years, will the Earth still be round?

Re:In 4 years?

[J_Doh!]

mmmmmmmmmmm popcorn!

Sorry to gloat, but

[Anonymous Coward]

My Zune 120, Thinkpad, Windows Mobile phone, Windows Home Server, Linksys router and Xbox 360 are all working just fine!

Re:Sorry to gloat, but

[lordtoran]

My Sansa with Rockbox, Mandriva laptop, Kubuntu netbook, LinuxMCE based DVR and my fluffy stuffed penguin are all working just fine!

Re:Sorry to gloat, but

[Malevolyn]

My wheel, abacus, mortar and pestle, and Galileo thermometer are all working just fine!

Deeper analysis of the bug...

[dmihalik]

Analysis of the bug can be found here and verbose loop analysis can be found here.

Who was expecting other solution than REBOOT?

[miknix]

anyway?

Paul

[Anonymous Coward]

Wait...
You guys assume the Zune will last another 4 years?

Amazing..

[NfoCipher]

The first step to fix any microsoft problem - reboot.

Re:Amazing..

[aliquis]

You write that as if it was a bad thing.

Proper name for this bug

[Anonymous Coward]

The "Shoodabottaeyepod" bug.

Re:Cause of the Zune crash? Third party drivers

[Skiron]

If that is a true post, and I think it is, it was the fact 1980 was also a leap year. So we had a last day of a leap year, and then just subtract 365/366 as appropriate 'if (IsLeapYear(year))', you will end up on the last day of 1980 - which isn't > 366 but it is > 365.

Heh. It just proves nothing was tested.

Wait until noon on January 1, 2009?

[RealGrouchy]

But I want my music back now!

- RG>

Re:slow news day?

[Anonymous Coward]

Well if it was known by you then it was known by everyone, right?

Instead of bothering with a fix

[dmomo]

Wouldn't it be faster for Microsoft to simply give each of the 8 users a call and walk them through the work-around? If their numbers change in the next four years, they can simply notify Zune support.

Re:Instead of bothering with a fix

[EvanED]

[posting to undo moderation... I chose the wrong post]

Re:Instead of bothering with a fix

[markpg]

.. or just fedex them iPods...

Re:Instead of bothering with a fix

[Anonymous Coward]

*Offtopic*

i must have extremely good (bad?) luck, because now http://socuteurl.com/foo points to slashdot.org

>_>

what are the chances?

Re:Instead of bothering with a fix

[Anonymous Coward]

hawww, cmon mods. don't be total asstards. parent had no choice but to post if he wanted to undo an accidental unfair moderation. he explained the reason he was offtopic. ie he was workin around /.s stupid no-undo moderation system.

give people a fuckin break you power mad wankers.

Re:Instead of bothering with a fix

[dmomo]

I suppose the chances are pretty close to this one!!

www.socuteurl.com/buggy

Re:Instead of bothering with a fix

[EvanED]

I don't care, and my post is offtopic (as is this one, so feel free to mod it down too). I've got close to 4000 posts (I can't find the exact number since /. made their user pages suck ass), a fair percentage of which are modded up and almost none of which are modded down, so it's not as if I'm hurting for karma. I'm more annoyed at having to undo another moderation I made in this topic. Oh well, c'est la vie. Thanks for sticking up for me though. ;-)

Draining battery all the way

[postmortem]

Can't be good.

I've seen this in laptops leading to drastically decreased storage capacity.

Re:Draining battery all the way

[cbhacking]

Modern (i.e. Lithium-ion) batteries don't mind that much at all. I've drained laptop, camera, and Zune (2nd-gen, it didn't get hit by this bug) fully with no noticeable loss. Heck, Nickel-metal-hydride batteries, and especially the really old nickel-cadmium batteries (both were used in laptops if you look far enough back) *needed* to be fully drained periodically - leaving them at full charge was what caused them to lose capacity.

Don't confuse car batteries (almost invariably some form of Lead-acid cells) with other battery chemistries. Batteries in consumer electronic devices are designed to tolerate draining.

My Experience

[syntap]

I hadn't turned on the Zune before I read about the problem, so I just left it off and turned it on the morning of Jan 1 and everything worked fine, no need to drain battery or anything.

The above is not an admission that I own a Zune, just what I theoretically would have done and the theoretical results, based on heavy pretend observations.

Zune 80

[rm999]

Does anyone know why the Zune 80s didn't crash? I assumed they ran the same software and similar hardware.

Re:Zune 80

[gparent]

You're assuming too much. (AKA you're wrong, they didn't run on similar hardware)

Re:Zune 80

[ShadoxPrime]

One would obviously assume your assumption is wrong. Come on, how hard is that?

Re:Zune 80

[Lars T.]

http://forums.zune.net/412486/ShowPost.aspx

Q: Why is this issue isolated to the Zune 30 device?
It is a bug in a driver for a part that is only used in the Zune 30 device.

Re:Zune 80

[cbhacking]

Zune 80s (in fact, all 2nd-gen and 3rd-gen Zunes) were designed in-house from scratch, not based on the Toshiba Gigabeat S (which, as the summary points out, was also affected). Shame on MS for not ensuring that the Gigabeat code was correct (the bug is a simple case of over-engineering a solution, easy to miss at first glance, but still should have been caught by QA) but at least the Zunes they designed entirely in-house worked fine (my 8GB 2nd-gen didn't have any problems either).

Out of curiosity...

[The Man]

Why does a music player need to know the date or time at all?

Re:Out of curiosity...

[Anonymous Coward]

Why does a music player need to know the date or time at all?

For the DRM to work.

Non-DRM using pirates win again, arrrr!

Re:Out of curiosity...

[loconet]

DRM has gotta be at the top of that list of reasons..

Re:Out of curiosity...

[Anonymous Coward]

It's an essential element of proof in establishing when you violated copyright law and caused untold millions in damages to the recording industry.

Re:Out of curiosity...

[pha3r0]

Prolly because of DRM. I would assume that they need the date because (i don't know much about DRM) the certificate issued to each player by the computer is only good for a certain amount of time, or something like that.

Re:Out of curiosity...

[Anonymous Coward]

So it can display the date and time.

Re:Out of curiosity...

[TheSeer2]

Because music players are so much more now.

Re:Out of curiosity...

[WaxlyMolding]

Why does a music player need to know the date or time at all?

Subscription music DRM.

Re:Out of curiosity...

[Anonymous Coward]

because a herd of slashbots would scream and wail that the iPod is better because it shows them the current time.

Re:Out of curiosity...

[ritcereal]

DRM

Re:Out of curiosity...

[Anonymous Coward]

DRM?

Re:Out of curiosity...

[AmberBlackCat]

For me, it helps for "smart playlists". I have iTunes set to automatically put recently added and recently played music on my iPod. The recently played list would get out of date if the iPod couldn't track when the music was played. And I agree with this guy. I use my iPod as a clock more often than I use my cellphone.

Re:Out of curiosity...

[Anonymous Coward]

Correct me if I'm wrong, but doesn't Zune allow you to share a file with someone for... how does it go... "three days or three plays"? That's why.

Re:Out of curiosity...

[base3]

So it knows when to expire the DRM-encumbered tracks that might have been loaded on it. Hell, I'm surprised it doesn't have GPS so it can enforce region restrictions on "content" too.

Re:Out of curiosity...

[Anonymous Coward]

Why does a music player need to know the date or time at all?

What does "god" need with a starship?

Re:Out of curiosity...

[Anonymous Coward]

So it knows when to stop you from listening to drm'ed songs.

Re:Out of curiosity...

[Anonymous Coward]

Why does a music player need to know the date or time at all?

For DRM?

Re:Out of curiosity...

[Anonymous Coward]

Had to respond.

It's due to the need for good old DRM. For example, time-limited content.

Sometimes, stuff like this is too amusing not to laugh at.

Re:Out of curiosity...

[Anonymous Coward]

Thats a good question. Simple answer: It doesn't, however people find it useful to look at the screen and have the time. The bigger part of your question "Why does the time cause a OS failure" is one that ought to be more closely looked at.

Re:Out of curiosity...

[Anonymous Coward]

Probably something to do with sync purposes.

Re:Out of curiosity...

[Anonymous Coward]

Obviously it needs to police your rights!
It's DRM encumbered, and it needs to call home ("subscription sync") from time to time to check that it's not yet the end of World, oops, MAFIAA.

Re:Out of curiosity...

[MikeBabcock]

sssshhhhhhhhhhhh!

Re:Out of curiosity...

[cbhacking]

Anything from month-to-month media rental (for example, the Zune Pass) to simply displaying the time like a watch (how many people do you know who pull out their cell phones to check the time? I know at least 4, and it amuses me to no end, but in any case a "current time" display was one of the most-requested features for the Zune 3.0 firmware).

Re:Out of curiosity...

[base3]

Probably already patented and royalties the only major barrier to the idea. Another is operation in areas with no reception, but that could be worked around (presence in a region enables that region for some period of time unless it detects itself in another region). I'll be quiet now :).

Following Microsofts support cycle

[pha3r0]

You should have a new one by the next leap year and if you don't (And assuming it does still work as it should) they will politly tell you they no longer support that device officially and offer to transfer you to some sales department or recommend you to a reseller(payed).

Re:Cause of the Zune crash? Third party drivers

[aliquis]

Which has also been said over at dapreview or if it was anythingbutipod. But good work as usual from the Slashdot crowd trying to diss Microsoft even if not appropriate. Bla bla co-developed with Toshiba bla bla.

Was it even? I thought they just took Toshibas platform for their first players? I may be wrong there thought.

Anyway not completely Microsofts fault that the supplied SDK/code/whatever for the platform used had bugs.

The "solution" may be a little lame but I wouldn't lame Microsoft for this to actually happen.

And you're still moderated 0 fÃr some weird reason, maybe people is busy moderating "haha" posts +5 funny.

Hard way

[Anonymous Coward]

When my zune crashed i opened it up disconnected the battery reconnected it, then started it up with back+center+right that way no need to reconnect hhd.

(but everything is formated)

Gigabeat S

[Chad FM]

The Gigabeat S is a wonderful piece of hardware, though lack of support by Toshiba ruined it; there are numerous bugs, including one which randomly formats the hard drive, yet there have been no firmware updates.

My Gigabeat S30 running Rockbox was not effected by the freeze, for (now) obvious reasons; Rockbox is wonderful.

It probably won't last another 4 downloads.

[Ostracus]

The source code that's NOT available.

It probably won't last another 4 complaints.

[Ostracus]

Q: How many 30GB Zune devices are affected? How many Zune 30GB devices were sold?

All 30GB devices are potentially affected.

Q: Will you update the firmware before the next leap year (2012)?

Yes.

http://zuneinsider.com/archive/2008/12/31/30gb-zune-issues-officialupdate.aspx

It probably won't last another 4 RMAs.

[Ostracus]

Good thing your post is warrantied for six years.

All they've done

[fm6]

... all Microsoft has done is to ask users to wait out the conditions that triggered the bug.

And considering that the bug only came to light two days ago, that's pretty good.

I speak from experience. I'm a tech writer, and I've written literally thousands of bug summaries for customer support web sites and release notes. (In 1999, I did almost nothing else.) Finding the problem, identifying a workaround, and getting it out to the public in such a short time is pretty impressive.

Presumably they're working on a patch, but they won't say they anything about it until it's ready to go. It's an ironclad rule that you never talk about these things before they're ready, not if you want avoid vaporware lawsuits. It should be obvious to anybody that creating, testing, and staging a software patch takes a lot longer than writing up a workaround.

Re:All they've done

[quanticle]

Of course, one can credibly claim that the bug should never have existed in the first place, given that the loop triggering the bug wouldn't have passed a code review in any half-decent software organization.

Re:All they've done

[Anonymous Coward]

Impressive? To find a bug so simple, repetable? Come on. I'm a software engineer.

Re:All they've done

[fm6]

I think "credibly claim" is a mild way of putting it. Not only did they neglect the code review, but it doesn't make sense to me that the code even exists. Doesn't Windows CE have libraries for converting data like this? Assuming, of course, the library was properly written. But that's the advantage of using a library instead of coding it yourself — any given bug is likely to bite somebody else before it bites you.

Alas, I've seen bugs even stupider than this. Once I documented a BIOS bug that was a botched workaround for a another BIOS patch, that was botched workaround for a hardware bug. The original hardware bug stemmed from the use of a realtime clock that gave the current year as one output. Somebody thought they could create a leap-year flag just by examining the last two bits in this register. That's equivalent to taking the mod 4 of the register, so that's a good test of the leapiness of the year value, right? At least until 2100 (which is not a leap year even though is divisible by 4), and the computer would certainly be junked by then.

Only problem: the RTC register didn't contain the calendar year. It contained the number of years since 1970. Thus the system had a calendar bug that became apparent every even-numbered year!

Re:All they've done

[drinkypoo]

And considering that the bug only came to light two days ago, that's pretty good.

Actually, it's pretty shitty. Because let's face it, Microsoft has an infrastructure in place for delivering this sort of information already, so releasing it is a non-issue; and all they had to do to find out this worked was pull a Zune battery and reconnect it, and see how the system was. And this is a seriously screwed workaround, because the Zune's battery doesn't want to be completely discharged. In fact, it frowns pretty heavily on that sort of activity. Battery abuse is a terrible, terrible thing. Of course, there's probably really no other solution that doesn't involve opening the Zune, or at least drilling a small hole in it :D

Re:All they've done

[fm6]

Actually, it's pretty shitty. Because let's face it, Microsoft has an infrastructure in place for delivering this sort of information already, so releasing it is a non-issue...

Dude, I do this shit for a living. Trust me, two days from first bug report to documented workaround is pretty damned good. Getting the information, writing it up, having it reviewed, staging it on the web site, all this takes time.

That's assuming that you follow proper procedure in creating your documentation. You can always have shortcuts. But it's the shortcuts that create this kind of problem in the first place.

Re:All they've done

[jc42]

You can always have shortcuts. But it's the shortcuts that create this kind of problem in the first place.

Usually, but not in this case. The shortcut would have been to make a 1-line call to existing library date routines. But the programmer chose to write an entirely new date-munging routine instead, using many lines of code. And unfortunately, the programmer was incompetent at doing even the simplest date calculations.

It can be truly impressive how incompetent most people, even professional programmers, can be at handling dates. You can see obvious signs of this in most software that deals with dates. The competent programmers understand that it's plain silly to attempt calculations on dates stored in human-readable forms. Almost always, the sensible thing to do is to translate such dates to a binary second counter, do the calculations, and then convert back to human-readable form. And resist every attempt by others to force the software to save the human-readable forms internally, since that just tempts incompetent programmers to do arithmetic on them. But you see junk code like this all over the place, doing arithmetic on fields within dates. And we keep reading about the disasters that result from such incompetence. We'll probably still have this problem in 2100, which all sorts of code will treat as a leap year.

Re:All they've done

[fm6]

The shortcut would have been to make a 1-line call to existing library date routines.

That assumes that the programmer was familiar with the date routine APIs. Obviously he wasn't. Writing a dozen lines of date conversion code may be less work than writing a single API call. But not as much as taking the time to look up the API. The shoddy organization of Microsoft API documentation doesn't help.

In Effective Java, Josh Bloch devotes a whole section to the hazards of not using available APIs. Obviously he's seen a lot of programmers do this. And not just for dates: the example he uses is generating random integers based on a random real stream.

I agree with all you have to say about shoddy date code, but disagree with you about the cause. You blame "incompetence." But what do you mean by that? Stupidity? I've seen some really smart programmers make really stupid blunders. (Which is why code reviews need to be mandatory.) Murphy's Law guarantees that mistakes get made, no matter how careful you are.

I blame mental laziness. In order to use an API properly, you need to take the time and effort to learn it. But when you have a lot of code to write and you're on deadline, it's easier to just hack something together instead of taking the time to study the API documentation. Which is often useless anyway.

Re:All they've done

[MikeBabcock]

You think there's some relationship between people at Microsoft knowing about or being able to identify this issue and the management listening and doing something about it?

Re:All they've done

[sjames]

Honestly, as much as I hate MS, tagging this particular bug with "Won't fix" isn't all that unreasonable. This, after all, the oldest model and many if not most of them will be replaced by the time this rolls around again. The few that are left will have a 1 day outage 4 years from now and then be good to go for another 4. By that time they'll probably all have failed anyway.

Re:All they've done

[fm6]

You're forgetting that the code base will still be around in 2012. So they have to do a fix. I don't suppose anybody will be motivated to download a firmware update just to get this fix, but there will certainly be other fixes!

Re:All they've done

[sjames]

I'm guessing since it's just the old 30GB Zunes rather than all of them that the code in question is already retired.

Why does a music player care what day it is?

[qazwart]

I can't say what Apple would do. But, this begs the question why a player that merely plays music needs to figure out what day it is. I can understand why something like the iPhone and iPod Touch might have a bug like this. (Actually, I can't because these both use a real OS). But the Zune is similar to my iPod Classic, and my iPod Classic doesn't know the date and time unless I set it.

Re:Why does a music player care what day it is?

[Shados]

Well, for one, the Zune has a clock. For 2, it has an application framework on it that may need date and time stuff (.NET framework, used among other things for XNA...for games...and those often need it). Zunes are somewhere in between the classic Ipod and the Touch, feature wise.

Re:Why does a music player care what day it is?

[Shados]

bah, just realized I read your post too quickly (which is sad considering how short it was). I set the clock on my computer too, doesn't mean it doesn't have an internal one for the rest :). Anyhow, the rest of what i posted still stands. Whoopsies!

Y2k bug!!!

[Anonymous Coward]

It's the Y2k9 bug wiping all our data!! Oh no, we're all gonna die!

Or not.

Furnace

[witherstaff]

I'm located in lower Michigan, my family has an HVAC shop. At retail a typical, top ranked by consumer reports, furnace is less than 2000. Of course if you toss on an air conditioner A coil and an outdoor condenser you'll easily far more than double just the cost of the equipment. Installation can also add on a significant cost - duct work can take a bit of time. There are many ways to add on even more cost to systems - go for a high pressure furnace (needing very small duct work) or go for very high efficiency outdoor condensers - like anything there are a lot of choices. But if you had a 5 year old furnace, no AC, that needed replacing with the equivalent model - like replacing a new zune - it'd be next to no installation.

I agree with your point though, there are many choices from the cheap to the not so cheap. If my $20 mp3 player bites the dust I won't even bother trying to figure out why. But with the zune costing up to $250, even 5 years later I'd be far more concerned about it not working. It's the buying something at a price, and from a company, that you expect to mean quality and turns out not to be, that gets me.

Workaround for Zune found

[SupremoMan]

Buy iPod!

Re:Workaround for Zune found

[SupremoMan]

One man's troll is another man's funny.

Re:Cause of the Zune crash? Third party drivers

[master_p]

Interesting case.

1) this bug is a logical bug. Could it be avoided by using more advanced programming languages? for example, a purely functional one like Haskell?

2) has anyone ever thought of doing a loop-less programming language? a language that somehow allows 'gotos' but does not have the problems of loops?

Fix the other bugs

[Taylor123456789]

Why do they have a calendar function in the Zune at all? IT'S A MUSIC PLAYER!

Now if they could only get the Zune to sync with my Vista 64, I could actually use my Zune.

http://windowsconnected.com/blogs/matt/archive/2007/11/13/zune-2-x64-software-doesn-t-install.aspx

There is no Data... There is only Zune

[sbillard]

I haven't seen it posted yet, but to me the obvious question is...
Why is my music player date/time sensitive?
Jesus Christ, corpse on a stick WTF does it matter and why am I denied access to my data when date = x?

DRM I suppose. Pointless instructions that cripple your shit.

No KLOCs at Microsoft

[benwaggoner]

It's hard to imagine any rating system that's more screwed up than the system used in most companies to rate the output of their programmers. If they were consciously trying to sabotage the software, they probably wouldn't come up with any schemes nearly as effective as judging programmers by lines of code produced.

Fully agreed. The other post's anecdote about having trouble getting a review by makign code smaller is quite telling.

Anyway, that kind of measurement certainly isn't done here at Microsoft (although plenty of productive programmers write a lot of lines of code). By example, great stuff like the speed/quality improvements in video playback and scaling in Silverlight 2 didn't really add much or any lines of code; it was about superior design. The guy who wrote that stuff may not rate that highly in KLOC/week, but he's certainly recognized as a rock star.

http://on10.net/blogs/benwagg/Silverlight-2-RC0-is-out/
http://on10.net/blogs/benwagg/Demo-of-Silverlight-2-scaling-quality-improvements/

Why I will no longer buy any Microsoft product

[Anonymous Coward]

Microsoft has so totally blown its credibility that I have determined never to purchase any Microsoft product in the future. My last MS purchase was XP on my Dell D630 laptop over a year ago. I have migrated totally to Linux (CentOS 5.2), OpenOffice for office automation needs (on Linux and XP), and GNU and other open source tools (Git, Eclipse, et al) for software development. At this point, I only have three programs on Windows platforms that I haven't been able to replace with Linux or open source versions - my stock/option trading software (proprietary), software modeling (Sparx), and DVD image ripping (Alcohol 120). So long MS, it was good to know you...