Y2.01K bug

[yoink]

Most of you have probably seen the news about the "new y2k" bug, as seen here. Note also comment 11 on that page:

my Navman PiN device suddenly said the date was 01/01/2016 and not 01/01/2010

Somewhere there is probably a common date library that calculates the date incorrectly - it is not a coincidence that "010110" = 16 converted from binary to hex

Anyone got any ideas what library it may be? So far the following devices / services have been affected:

• BOQ ATM machines
• Navman PiN (as comment on the BOQ story)
• Palm Pre syncing Calendar with MS Exchange
• 30 million bank cards hit by 2010 bug
• Y2.01K bug trips up Symantec

I think the Navman runs on windows mobile 2003? Obviously Exchange runs on windows, but I'm not sure that it is not the pre-s fault.

Anyway, if you find any other devices / services that have this issue, let me know, and I'll list them here; this could be rather big by tomorrow, when everyone gets back to work...

[yoink]

Discussion on slashdot here, consensus for the SMS bug seems to be that some phones are treating the timestamp as hex rather than a two-digit BCD value as per the spec. This is most likely similar to what has happened to other devices too...

Edit: this thread blames it on "Swapped Nibbles", and confusion about endianness, can someone more knowledgeable about this issue comment?

[0restes]

The irony of your avatar does not escape me.

[mikeyyy]

I skimmed over it, but it seems that for the SMS one, apparently the spec says the year is sent as one byte encoded in BCD.

The upper 4 bits represent the 1's digit, and the lower 4 bits represents the 10's digit. The year is stored only as 1 byte, apparently because the SMS format pre-dates Y2K and the century is inferred by the date set on the phone. So you set the date to be 2005, and the year part that is sent is simply the 05, no mention of the 20.

This is sent in BCD as 0x50, taking the 20 from the year on the phone, and read 0x50 as 05, you get 2005.

This is where I get confused, if the above is true, then the date for 2010 *should* be represented as 0x01. In their BCD encoding this means 10, but in hex it means 1. Which would give 2001, not the 2016 they're getting.

You mentioned a confusion over endianness, which usually means the order bytes are stored, but in this case maybe the order of the 4-bit chunks (or nibbles) are stored. If you read 0x10 as 10 and not 01, opposite to the spec, then 0x10 should be 10 in BCD, or 16 in hex.

If the phone SMS software treats the byte as a hex number, it'll print 2016. If it was properly treated as BCD, technically it should be 2001, that is if the spec I found linked on your sites is the right one. If that spec is wrong, and 0x10 does mean 10 and not 01, then all makes sense...

The spec linked was http://www.dreamfabric.com/sms/scts.html, and if you follow the example, you'll see each byte is read in reverse to get the numbers out.

[Fishmaster]

Anyone seen any other areas its messing up? We've been watching some of our older programs for any bugs or mess ups but nothing sofar, seems to be only hitting SMS and ATM's.

[yoink]

Originally Posted by 0restes

The irony of your avatar does not escape me.

Originally Posted by mikeyyy

<techinal explanation>

Thanks for that, makes a bit more sense

Originally Posted by Fishmaster

Anyone seen any other areas its messing up? We've been watching some of our older programs for any bugs or mess ups but nothing sofar, seems to be only hitting SMS and ATM's.

Check this out: 30 million bank cards hit by 2010 bug

Excerpt:

AROUND 30 million high-tech German bank cards could leave owners high and dry, bank associations warned as the feared Y2K computer bug struck 10 years later than expected.

The problem that hit cardholders trying to use cash machines or make payments throughout Germany and abroad stems from computer chips unable to recognise the year 2010, and could take up to a week to resolve, the DSGV savings and regional banking association said in a statement.

I love how they blame the "Y2K computer bug", it's a "date miscalculation" at best...

[houseofzeus]

Originally Posted by yoink

I love how they blame the "Y2K computer bug", it's a "date miscalculation" at best...

Realistically in most cases it's going to be a miscalculation introduced as a result of the original attempts to fix/workaround Y2K so it's not that far off the mark.

[yoink]

Originally Posted by houseofzeus

Realistically in most cases it's going to be a miscalculation introduced as a result of the original attempts to fix/workaround Y2K so it's not that far off the mark.

I doubt it - the SMS spec was around before Y2K, and the y2k issue is not really related to this problem. I think it is more of a case of the media trying to compare the problem back to something that people can relate to.

[Tekin]

http://www.theregister.co.uk/2010/01...tec_y2k10_bug/

this one is of relatively minor impact - but still rather entertaining.

[MrSnuffy]

The SpamAssassin one was a little more 'duh' (and was admittedly fixed last year... but who deploys patches, really?!)

If $date > 2010 : then "too far into future, must be spam"

heh.

[yoink]

Originally Posted by Tekin

http://www.theregister.co.uk/2010/01...tec_y2k10_bug/

this one is of relatively minor impact - but still rather entertaining.

Nice one! - I wouldn't call not getting AV updates minor, that's rather bad actually...

[houseofzeus]

Originally Posted by yoink

I doubt it - the SMS spec was around before Y2K.

Which accounts for one out of a growing list of systems encountering problems. I'm not saying it *is* the Y2K problem, just I don't think it's that unreasonable for the media to be referring to it this way given there appears to be a link in at least some cases.

[Tekin]

Originally Posted by yoink

Nice one! - I wouldn't call not getting AV updates minor, that's rather bad actually...

Nah - the updates are still coming through, but they are just force dating them all to be 31/12/2009.

So far we've received 3 updates on the same date. from R113-R116 all dated 31/12/2009

[Foliage]

Sounds like a simple BCD -> hex conversion going wrong. I've done this countless times when writing real time clock routines for PIC microprocessors. Usually because I'm lazy and guess without actually working it out on paper before hand, then when it goes wrong I shotgun debug, the difference here is I actually unit tested my date and time stamps to make sure they were correct in the end.

Shouldn't be too hard to fix.

[chancey]

Originally Posted by yoink

Most of you have probably seen the news about the "new y2k" bug, as seen here. Note also comment 11 on that page:



Somewhere there is probably a common date library that calculates the date incorrectly - it is not a coincidence that "010110" = 16 converted from binary to hex

Anyone got any ideas what library it may be? So far the following devices / services have been affected:

• BOQ ATM machines
• Navman PiN (as comment on the BOQ story)
• Palm Pre syncing Calendar with MS Exchange
• 30 million bank cards hit by 2010 bug
• Y2.01K bug trips up Symantec

I think the Navman runs on windows mobile 2003? Obviously Exchange runs on windows, but I'm not sure that it is not the pre-s fault.

Anyway, if you find any other devices / services that have this issue, let me know, and I'll list them here; this could be rather big by tomorrow, when everyone gets back to work...

I like the irony that everyone was so scared about planes crashing and missiles going off with the Y2K bug and nothing happened, then it hit us 10 years later.