Adobe and Apple Didn't Unit Test For "Forward Date" Bugs. Do You? 169
llamafirst writes "As the year flipped to 2013, we learned that Adobe and Apple don't test for "forward date" bugs. Adobe prevented any copy of FrameMaker 10 from launching and Apple broke Do Not Disturb for the first week of 2013. Surely some more critical and safety systems also have lurking issues. Got tips for catching time/date bugs 'from the mysterious future?' (Also, obligatory link to Falsehoods programmers believe about time.)"
leap year (Score:4, Interesting)
Re: (Score:2, Informative)
It seems like every 4 years on leap year, one of Microsoft's products breaks in a hillarious way. This year, it was Microsoft Azure (which was completely unavailable). 4 years ago, it was Zune and Exchange 2007 (Zunes simply did not function, Exchange had some management issues).
Not sure if they had anything in 2004, like SBS2003 devouring all files edited that day or something, but Id be interested to know.
Forward testing (Score:5, Funny)
Well, there was no point in forward testing after Dec 21, 2012, you see.
Re:leap year (Score:4, Informative)
Christ. Year after year, iOS alarm clock, DND, or something breaks on new years, leap year, DST, or something.
IT JUST WORKS!!!!!
https://discussions.apple.com/thread/3795574?start=0&tstart=0 [apple.com]
http://www.engadget.com/2011/03/14/ios-daylight-saving-time-woes-continue/ [engadget.com]
Re:leap year (Score:4, Interesting)
Yeah, I don't entirely understand why apple is having such a rough time getting basic time keeping and scheduling working...
Re: (Score:3)
Yeah, basic mobile phones deal with this problem much better than Apple, probably by doing nothing and just asking the GSM net what time it is. Why handle DST when the network can tell you what the local time adjusted for all recent legislation and leap seconds is?
Re: (Score:2)
Because iOS also runs on non GSM devices such as iPods and iPads and therefore cannot always depend on a network to handle time.
Re: (Score:2)
>Why handle DST when the network can tell you what the local time adjusted for all recent legislation and leap seconds is
Because some networks either don't send the time or are just plain wrong? I always have to switch to manual time setting when traveling through certain countries.
Shouldn't Be A Problem... (Score:1, Funny)
The world will end on December 21, 2012 anyway.
Re: (Score:2)
Re: (Score:2)
It did, and we are all now posting from hell.
No change there then.
or the new calendar with a leep week (Score:2)
http://henry.pha.jhu.edu/calendar.html [jhu.edu]
Neither did Google (Score:3, Informative)
They left December out [techcrunch.com] of Android Jelly Bean's date picker.
Re: (Score:3)
Has anyone come up with a good way to test user interfaces yet other than to have someone sit slack-jawed and wiggle everything they see on the screen for hours on end?
Re: (Score:2)
I don't know about "good" but for Android there is Monkey Runner [android.com]
I don't think that would have saved December though.
Maybe a unit test should assert that there are 12 items in the month list though.
Re: (Score:2)
Sorry to reply to self but should add that the Android class for UI testing would be TouchUtils [android.com]
Re: (Score:2)
Has anyone come up with a good way to test user interfaces yet other than to have someone sit slack-jawed and wiggle everything they see on the screen for hours on end?
The Java Robot class is built into the standard library and can be used to control mice, keyboards, and features screenshot capability. If you can come up with a way to convert menu selections in your application into a function call like selectMonth(2013,'March'), then you compose all of the related screenshots generated together. Now your slack-jawed guy just needs to play a game of spot the differences.
I am sure better options exist.
Re: (Score:2)
Robot is part of the awt package and thus is not supported on Android.
http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/Robot.html [oracle.com]
The (better IMHO) Android class would be TouchUtils [android.com]
(Though it seems to be missing screenshot capability. )
Re: (Score:2)
My shop used Rhino (JS running in the same JVM as your Java) to write JS automated test scripts. We've got about 800 of them now, and it's awesome. We've built it to run on multiple machines, aggregate logging, report failures, all built into our nightly build with Jenkins so we sit down in the morning and there's a list of issues waiting for us on all new code builds.
Re: (Score:2)
One example for java (there are others): http://code.google.com/p/windowlicker/ [google.com]
OP change the title (Score:2, Insightful)
Why add "Unit Test?" just say "Test" unless you really mean a unit test.
Trouble for them (Score:1)
Watching my Linux Mint laptop closely. (Score:2)
Why? (Score:5, Interesting)
Why does software functionality depend on the date? Calculation issues maybe... but failure to lauch? WTF? I'm most curious to learn how this even happens.
Re: (Score:3)
Stupid copy restriction?
Re: (Score:2)
You mean outside of software like ntp, Kerberos/AD, motion calculations, astronomical calculations, GPS.
Just to name a few things off the top of my head.
Re: (Score:3)
These depend on time, not date.
Re: (Score:3)
Some kind of half-assed copy protection or trial use. "Dude, you totally changed the date to get around our 30 day trial! No more software for you!"
Stupid, yes. But it exists.
Re: (Score:3)
See this link for an example: http://www.wmusers.com/forum/archive/index.php/t-5470.html [wmusers.com]
webMethods' 'Trading Networks' B2B integration software (now owned by Software AG) used a GUID-generator routine which created 24-byte GUIDs for processing B2B documents. One of the inputs to this routine was the number of milliseconds between UTC and UNIX epoch.
One day in 2004, the progress of time caused 25-byte GUIDs to be created. Trading Networks tried to insert these into a database column whose width was 24 byte
Re: (Score:3)
Re: (Score:2)
One word: DRM. I bet that some sort of validation was date-dependent and with the year rollover, it got wrecked :)
Just my two euro-cents :)
Re: (Score:2)
In the case of Adobe, it is (as is often the case) the stupid license management that broke the program.
I've had the opposite experience.... (Score:4, Interesting)
I've had mock SSL certs and HTTP cookie jars that both expired and made it seem like the system was failing all over the place during unit/integration/general testing.
So just watch out in general because this can swing either way...
Re: (Score:2)
Re: (Score:2)
I bet your test system came to a screeching halt though, so it's still good!
Re: (Score:2)
funny real event: Co-worker could not get his email client to work. Connection is managed using SSL, and the tunnel setup was failing. The reported error was a certificate invalid. That didn't jive with the CA cert - it was issued a year ago and is good for like 20 years.
After looking and looking and looking: He realized his system date was set to 1/1/1980 - his CMOS battery was dead.. Jan 1 1980 is prior to the start of the validity period for the CA cert in use.. ;)
Re: (Score:2)
Yeah, that's happened to me. Shouldn't that just work, though. I mean unless you've invented time travel, why wouldn't you accept a cert that's before its validity period? Is there a vulnerability use case that I'm not aware of?
Re: (Score:2)
Re: (Score:2)
I can see it adding a little bit of security by obscurity by requiring an attacker who has acquired an expired cert to set the clock back just the right amount before using it, rather than just resetting to the middle ages. Of course, if you can set the clock on someone's machine you probably have little need to convince it to accept a bad cert ...
Re: (Score:3)
Yeah, that's happened to me. Shouldn't that just work, though. I mean unless you've invented time travel, why wouldn't you accept a cert that's before its validity period? Is there a vulnerability use case that I'm not aware of?
If your clock is resets to 1980, you don't know which certificates have expired. If you accept all, you run the risk of accepting a genuinely expired certificate. Although it would be more helpful to have the OS report implausible dates.
Re: (Score:2)
Re: (Score:2)
Your tests weren't buggy ... (Score:2)
I've seen a vendor issue a super-urgent patch. IIRC, it contained an update to an expiring CA certificate. They could have forseen this issue with time-shift testing of the type you did (which 'breaks' your test, but it also proves the need to install update CA certs by a future date)
My other post has an example why time-shift testing is important.
http://apple.slashdot.org/comments.pl?sid=3356429&cid=42472583 [slashdot.org]
(It was the same vendor in both cases)
Simple... (Score:2)
Oh, dynamically calculated dates need to factor in the 12/31 to 01/01 change, formulas / functions that work the other 364 days tend to fail here in their first year in production a lot. That only applies to the actual year switch though, and when the app/report is specifically run on
Re: (Score:2, Insightful)
I think all dates and times should be stored in UTC (not GMT). Storing them in anything that is affected by time zones and DST is just asking for trouble. DST and Time Zone are presentation problems ... not storage problems.
Re: (Score:2)
OK, so how will you solve the GP's problem then? Or to put it another way, here are two future meeting dates. Which one has been updated to reflect the new timezone, and which one has not:
I'm not saying that the GP's solution is perfect, but you've completely ignored the problem in making your comment. Unfortunately we live in a time where politicians and lobby groups think time is pretty flexible (sorry about the pun). So you probably need to store in UTC
Re: (Score:2)
I'm not sure you understand what I mean. A UTC time is not affected by timezone or daylight savings time. If you store local dates in the current timezone, it's affected by both. At least twice a year you're screwed for an hour and don't really know what time it is. UTC times can be displayed in any timezone/DST combination you like ... they're absolute times. I work on international systems that deal with these problems all the time. Saving times in UTC is the only way that actually solves all of the probl
Re: (Score:2)
To elaborate, I would recommend storing dates as seconds (or milliseconds if you need that resolution) since a well defined epoch in UTC (Unix uses 00:00:00 UTC on 1 January 1970, before macs switched to unix, they used January 1, 1904 and January 1, 1601 for Windows). You can go from there and convert to whatever timezone you like.
Re: (Score:2)
So let's say I schedule a meeting with you at 10 AM on August 1. If we take brain-dead-simple NA DST rules, your UTC appointment now occurs at 9AM. Ah, but I said 10, so you'd be
Re: (Score:2)
of course when converting from natural date to offset from epoch, you use a database [iana.org] that keeps track of the details as to what offset from UTC is used when. That said, date math is a fucking PITA even when you have all the tools at hand.
Re: (Score:2)
Hmmm. Given a appointment on October 1st, 2014, 22:00. Appointment is in a country that has no summertime/wintertime difference. GMT/UTC offset is say +1:00.
On February 1st, 2013 the government decides that from September 2013, there will be a summertime/wintertime difference. Wintertime offset will be +2:00.
When stored in UTC, the appointment is now rendered with a local time of October 1st, 2014, 23:00. IMHO, the timezone, and the timezone offset are not just presentation issues; they are an implicit par
Re: (Score:2)
That is correct. You also need to store *when* it was created if you want to handle DST changes in some cases, depending on how you want to use the dates.
Re: (Score:2)
Unless they are user alarms, opening hours etc. A lot of things need to _not_ be adjusted for DST, if you stored them in a absolute format, you would suddenly need to adjust them.
2038 (Score:4, Informative)
I for one am stockpiling canned meat in my bomb shelter for 2038 [wikipedia.org]. By the time 2038 comes, software will be so virtualized and there will be so many layers between operational computer software and what's under the hood that it will take at least a decade to fix this problem in our future society.
Re: (Score:2)
the mainstream virtualization wares used at enterprise level already use 64 bit time
some control and embedded system are more like to be troublesome, but the failures will be sporadic. stay out of your bomb shelter and laugh at the companies who lose
Re: (Score:2)
the mainstream virtualization wares used at enterprise level already use 64 bit time
some control and embedded system are more like to be troublesome, but the failures will be sporadic. stay out of your bomb shelter and laugh at the companies who lose
You cunning son of a bitch... You're just saying that to lure me out of my bomb shelter!
Re: (Score:3)
Have your forward-date tested the edibility of your canned spam?
If you plan to eat it in 2038, you really, really should, :)
Time. . . (Score:2)
Re: (Score:2)
never been to Tokyo or Kuala Lumpur or Tapei? some asian societies take the concept of workaholic to the next level....
Re: (Score:2)
Truly a different mindset.
Re: (Score:2)
Knowing what time it is implies you are looking for quitting time. If you work 24/7 you don't need to know what time it is!
Now get back to work!
Unit Test? (Score:1)
What does this have to do with Unit Tests?
Re: (Score:2)
Other than that fact that good unit tests would have caught this problem, not much.
Nope (Score:2)
Re: (Score:2)
Not to mention that 30 Dec 2012 was a Sunday....
one of these days (Score:2)
I am itchin to fire up the old minicomputer and see what it thinks of 2013..of course i have been saying that since Y2K. Too bad it would mean turning off all the electrical stuff in my house to get enough juice to spin up the HD :O
1983 Wang computer..the login screen had calenders loaded until 2030 was always curious if it really would have been ok but noone wanted to risk it and it was retired in 1998. Can't believe it's been 14 years and i haven't even seen if it still works, altho that 1960 watts draw o
Re: (Score:2)
should be fine,internal dates are stored as YYYYMMDD including in PACE database. People still run Wang software virtualized on intel hardware from TransVirtual Systems http://www.transvirtualsystems.com/ [transvirtualsystems.com]
Automated testing (Score:3)
My shop has over 800 automated test scripts, all of which have been running on machines that think it's 2013-2014 for over a year, and will be bumped up to 2014-2015 by the end of the month.
Re: (Score:2, Insightful)
Re: (Score:2)
This.
Dates are not hard! (Score:2)
This other /. artical says it best How Can I Explain To a Coworker That He Writes Bad Code? [slashdot.org]
It's now almost 35 years ago, when I had to write date routines that spanned the year 2000 and only use 2 char year, and only use the same 5 nibbles of storage that the julain date was stored in, in the end that system could handle a ~250 year period it took about about 500 Bytes of size. Then I wrote a rouitne that in 13 nibbles handle that same time period got us down to 8ms ticks. We then used them every where in
Intricacies of time (Score:2)
Specifically temporal consistency. A guy by the name of Snodgrass wrote a book on it and I urge everyone to al least skim through it. See his website: http://www.cs.arizona.edu/~rts/ [arizona.edu]
Falsehood 35: (Score:2)
No one would be stupid enough to set the system clock to local time.
Bad Assumptions About Dates and Times (Score:2)
Here is one that really bit me in the ass once. Daylight Savings Time happens on different days depending on which country you are in, and the operating system doesn't always know when this should be.
Back in 2007 I was deployed to Iraq supporting military systems. In Iraq, Daylight Savings happened on April 1st and October 1st, but Windows didn't know that. Using the Baghdad time zone Windows thought that daylight savings happened on the same days that it did in the US. So, for about a week, every compu
Re: (Score:2)
All sane* databses store time as seconds since epoch. That's a format that can be converted to GMT without error whatever are the settings of your OS. The user interface, by the other side, rarely uses a simple format, and will often translate things wrong.
* Yes, if your database doesn't do that, it's insane. so are its
Re: (Score:2)
Framemaker still exists? (Score:2)
Re: (Score:2)
I suspect you're thinking of PageMaker, which was replaced by InDesign. FrameMaker is a whole different popsicle stand; as I understand it, it's the difference between laying out a page, and laying out a whole book.
Careful setting dates (Score:2)
In late 1999, we tested a product by rolling the date forward to 2000-01-01 and it worked fine. Then we rolled the date back to the normal date, and files that got touched during the test period caused trouble, because their modification date was "IN THE FUTURE!?!?!?" as one piece of code put it. The most broken was the timestamp data for a time-based UID generator, which flat out refused to run, saying that it was in danger of generating collisions.
Good programming (Score:2)
Re: (Score:2)
If that is causing your software to crash or to start have issues then STOP PROGRAMMING! Proper programming prevents those kind of issues. I'm not saying that you shouldn't test for this kind of issue but if you program properly in the first place a date overflow wont crash your software. You tend to see this kind of error with Object Oriented programmers, a good C programmer will have handled this before it happened.
A good programmer would have handled it, period. As others have mentioned, there are very few excuses to handle time as anything but an offset from epoch. It's no different in the object-oriented languages I know.
Re: (Score:2)
Re: (Score:2)
Abode not test their stuff? (Score:2)
Surely you jest. Well at any rate I'm sure they'll fix it with an 857MB patch to Adobe reader.
Apple's bug explained - Or why it autofixes itself (Score:2)
The Apple one is really odd - because if you read Apple's response, it makes no sense. It automatically fixes itself on January 7? WTF? Date/time bugs don't usually have self-expiry dates (though Apple's response is adequate since the bug will auto-fix itself before Apple could fix and test the update). And especially since there's nothing seemingly *special* about January 7...
Ars has a nice write up about it - http://arstechnica.com/apple/2013/01/ask-ars-why-will-apples-do-not-disturb-bug-fix-itself-next-w [arstechnica.com]
Not just pc software (Score:2)
It happens. For example, in the late eighties, when I was still on a mainframe, halfway through my stint at at Fortune 500 company (referred to, ever since, as the Scummy Mortgage Co, SMC, actual name available upon request, and for many, many, many reasons), they fired (not laid off) the other online programmer, who'd been there 10 years. A few months later, I found his "algorithm" for leap year in most of the online systems: if it was 76 or 80 or 84 or 88 or 92, it was a leap year.
I kid you not.
I went to
Beware of Jan 1, 2022!!! (Score:2)
I found an "amusing" bug in a software deployment system recently that will break horribly on Jan 1, 2022. (Much sooner than the usually announced doom-dates of 2038 and such).
It's a fairly simple cock-up, so I wouldn't be surprised to find it elsewhere.
Step 1: Make decisions based on a datestamp.
Step 2: Define that datestamp as "YYMMddHHmm".
Step 3: Somewhere along the line, shove that string into a 32bit signed integer.
The maximum value we can store is thus "2147483647", so the "2201010000" of Jan 1, 2022
Very simple...but misses many common needs (Score:4, Insightful)
Frequently, calculations require both points in times and intervals of time; the former can consistently be represented as seconds since epoch, the latter doesn't really have a usable equivalent (you could use just seconds, but then things don't work as expected, since often its actually important to the user that the interval be an exact number of days, weeks, months or years, which may not be reducible to a consistent number of seconds, but instead that will depend on how the point in time the offset is being calculated against is represented in Year/month/day/hour/minute/second form, because leap seconds, leap years, and different lengths of months all make interval calculations tricky.)
You can't restrict conversion of seconds-since-epoch to calendar format to display-purposes-only if you are going to do anything useful with dates.
Re: (Score:3)
Bull, I find bugs all the time *because* dd/mm/yyyy in applications is often stored/operated on with millisecond/second precision.
Let's see:
a) the case of the missing midnight: some date or another in the 1920's IIRC that doesn't have a 00:00:00 hour but that day starts at 02:00:00 hour (so, two missing hours). Unable to create or store that date with the time set at midnight.
b) range 01/01/2012 - 10/12/2012 entered by the user, inclusive. On 10/12/2012 00:00:01 the system determines the current date is no
Re: (Score:2)
b) range 01/01/2012 - 10/12/2012 entered by the user, inclusive. On 10/12/2012 00:00:01 the system determines the current date is no longer in the range. Bug, certainly not what the user intended.
How do you make an inclusive range of ANY value that you'll store on a medium with higter resolution than your range? Ans. You add 1 to the end point, and store as a not inclusive range. (You will also want to subtract 1 of the high resolution units if you are storing it in a countable representation.) Nothing different for dates.
c) amount of days between 1/1/2012 CET and 1/6/2012 CEST. A naive way to calculate this is is to subtract the two dates (with millisec precision) and divide by 24 hours. That will give the wrong answer though.
That's still not a reason for not representing your time in seconds since epoch. Any representation that solves this problem will make it hard to order timestamps and calculate the
Re: (Score:2)
No matter how smart you think you are, you will get screwed trying to roll your own date handling.
So you're telling me that I should trust the date-handling library routines provided by hugely successful corporations like Adobe and Apple, right? ;-)
And yes, I have seem my code's time handling badly screwed up because I trusted the delivered library routines. So I learned to test them thoroughly, and in a few cases, I've had to replace them with routines that were correct. Granted, I usually got these from online open-source repositories, but in a few cases I've had to augment these with some code
Re: (Score:2)
How many people will be using a 50+ year old OS/app in 2050 when it would become a problem?
Re: (Score:2)
Ah yes... Back when 1999 turned into 2000 we did have a small Y2K problem... We used a support system written in perl where the naive programmer assumed that the year provided by the 6th field of the localtime decoder was the two last digits of the year. So to get the actual real year he prefixed the year with '19' as a string. This works fine until the year 2000 is reached. As the 6th field of localtime is the number of years since 1900, not just the last two digits, the year becomes 19100, not 2000. This
Re: (Score:2)
don't forget mysql (regardless of platform) will also fail. I'd be even more worried about embedded systems than any silly pc or server.
Re:Correct on embedded, see link... apk (Score:4, Informative)
I could supply link, or better yet let's make the proof this thread. See how timestamp beyond 2038-01-19 03:14:07 gets foobared.
rubycodez@hyperion:~$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 40
Server version: 5.5.28-0ubuntu0.12.04.3 (Ubuntu)
Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> create database timedb;
Query OK, 1 row affected (0.00 sec)
mysql> use timedb;
Database changed
mysql> create table tvalue(t timestamp);
Query OK, 0 rows affected (0.00 sec)
mysql> insert into tvalue values ('2012-12-21');
Query OK, 1 row affected (0.00 sec)
mysql> insert into tvalue values ('2038-01-30');
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> select * from tvalue;
| 2012-12-21 00:00:00 |
| 0000-00-00 00:00:00 |
2 rows in set (0.00 sec)
mysql>
Re: (Score:2)
yes, that is 64 bit, the issue is in how mysql stores the data not OS
Re: (Score:2)
it's a poor design, it will cause problems for applications such as mortgage or actuarial tables
Re: (Score:2)
and daylight savings time is the worst idea ever!
and any number of economist types have even told us that it totally fails at its advertised advantages. ;-)
But I wouldn't call it the worst idea ever. It's social and economic problems aren't in a league with such ideas as slavery, war, and religion. ;-)
Re: (Score:2)
As long as your system uses milliseconds since the epoch internally, daylight savings (and leap years, and leap seconds) are all simple problems of translation for human-readable display and will not effect functionality.
It's the difference between what we "call" a particular point in time and how much time has physically elapsed.
That said, I'm completely not sure how to properly deal with computers in highly accelerated reference frames who will have experienced a different quantity of elapsed time than th
Re: (Score:2)
I actually knew of an old mainframe system that had to be switched off for an hour when the clocks went back so that it didn't get confused and try to log the same time twice.