Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Adobe and Apple Didn't Unit Test For "Forward Date" Bugs. Do You?

timothy posted about 2 years ago | from the everyone-misses-a-few dept.

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

cancel ×

169 comments

Sorry! There are no comments related to the filter you selected.

leap year (3, Interesting)

d3matt (864260) | about 2 years ago | (#42468371)

2012 cost us a decent chunk of change because for the third product line in a row, we screwed up seconds since epoch calculations... Every single customer was out of commission until we released a patch!

Re:leap year (1, Informative)

LordLimecat (1103839) | about 2 years ago | (#42468635)

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.

Re:leap year (-1, Troll)

sconeu (64226) | about 2 years ago | (#42468705)

"unes simply did not function"

And how was that different from non-leap years? Or any other time at all?

s/unes/Zunes/ (0)

sconeu (64226) | about 2 years ago | (#42469635)

Forgot to preview

Forward testing (4, Funny)

fyngyrz (762201) | about 2 years ago | (#42468711)

Well, there was no point in forward testing after Dec 21, 2012, you see.

Re:leap year (3, Informative)

LinuxIsGarbage (1658307) | about 2 years ago | (#42470101)

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]

Shouldn't Be A Problem... (1, Funny)

lobiusmoop (305328) | about 2 years ago | (#42468381)

The world will end on December 21, 2012 anyway.

Re:Shouldn't Be A Problem... (-1, Redundant)

Hentes (2461350) | about 2 years ago | (#42468743)

Maybe they were using a Mayan calendar.

Re:Shouldn't Be A Problem... (1)

Sponge Bath (413667) | about 2 years ago | (#42469007)

It did, and we are all now posting from hell.

Neither did Google (3, Informative)

Anonymous Coward | about 2 years ago | (#42468401)

They left December out [techcrunch.com] of Android Jelly Bean's date picker.

Re:Neither did Google (2)

Qzukk (229616) | about 2 years ago | (#42468579)

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:Neither did Google (1)

alostpacket (1972110) | about 2 years ago | (#42468643)

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:Neither did Google (1)

alostpacket (1972110) | about 2 years ago | (#42469199)

Sorry to reply to self but should add that the Android class for UI testing would be TouchUtils [android.com]

Re:Neither did Google (1)

feedayeen (1322473) | about 2 years ago | (#42468799)

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:Neither did Google (1)

LordStormes (1749242) | about 2 years ago | (#42469217)

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:Neither did Google (0)

Anonymous Coward | about 2 years ago | (#42470777)

have someone sit slack-jawed and wiggle everything they see

It works for my pecker.

Re:Neither did Google (0)

Anonymous Coward | about 2 years ago | (#42469485)

Apparently Google's infrastructure can collapse if the times are off by as much as a second... so they spread leap seconds out over a long period. This is way scarier than some date picker not working or appointment not showing up. You can use paper for your reminders or tie a string to your finger. But if Google bugs out it can take a lot of the internet with it.

OP change the title (2, Insightful)

Anonymous Coward | about 2 years ago | (#42468419)

Why add "Unit Test?" just say "Test" unless you really mean a unit test.

Trouble for them (0)

gmuslera (3436) | about 2 years ago | (#42468429)

The "Broken by design" paradigma is already patented by Microsoft. Hope they have some spare billons for the incoming lawsuit.

Watching my Linux Mint laptop closely. (1)

Andy Prough (2730467) | about 2 years ago | (#42468829)

I'm sure it will break at any moment, since it's not supported by a big, expensive company like Apple or Adobe. Think I will see smoke first?

Why? (4, Interesting)

gr8_phk (621180) | about 2 years ago | (#42468431)

Got tips for catching time/date bugs "from the mysterious future"?

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:Why? (2)

Tanuki64 (989726) | about 2 years ago | (#42468473)

Stupid copy restriction?

Re:Why? (0)

Anonymous Coward | about 2 years ago | (#42468485)

Licensing checks? Checking for updates as part of starting up?

Re:Why? (0)

Anonymous Coward | about 2 years ago | (#42469193)

Well, if that's the case the answer is "don't do licensing checks".

If you do that based on the date, you'd better be prepared to test the software for each and every time and date.

Simple, really.

Re:Why? (1)

NatasRevol (731260) | about 2 years ago | (#42468801)

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:Why? (0)

Anonymous Coward | about 2 years ago | (#42469959)

He asked why it would fail to launch not why the calculations might be wrong. Name a few more and actually think about it smart ass.

Re:Why? (2)

Hentes (2461350) | about 2 years ago | (#42470627)

These depend on time, not date.

Re:Why? (0)

Anonymous Coward | about 2 years ago | (#42469033)

DRM

Re:Why? (0)

Anonymous Coward | about 2 years ago | (#42469213)

Got tips for catching time/date bugs "from the mysterious future"?

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.

Licensing restrictions would be my guess.

Re:Why? (2)

Zadaz (950521) | about 2 years ago | (#42469493)

Why does software functionality depend on the date? Calculation issues maybe... but failure to lauch? WTF?

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.

Review (0)

Anonymous Coward | about 2 years ago | (#42468447)

Adobe's case? No, because I don't implement fucking DRM. Also, ha ha, pirates again score the better product versus honest customers.

Apple's case? Absolutely, because behavior is supposed to change based on calendar events. We have some unit tests for that, right?

I've had the opposite experience.... (3, Interesting)

Zapotek (1032314) | about 2 years ago | (#42468457)

...with forward dates braking my tests.
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:I've had the opposite experience.... (1)

Zapotek (1032314) | about 2 years ago | (#42468469)

Damn it! *breaking* /facepalm

Re:I've had the opposite experience.... (1)

Qzukk (229616) | about 2 years ago | (#42468563)

Damn it! *breaking* /facepalm

I bet your test system came to a screeching halt though, so it's still good!

Re:I've had the opposite experience.... (2)

muddysteel (1404041) | about 2 years ago | (#42468701)

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:I've had the opposite experience.... (1)

Bill, Shooter of Bul (629286) | about 2 years ago | (#42468953)

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:I've had the opposite experience.... (0)

Anonymous Coward | about 2 years ago | (#42469069)

Yeah. It's used so that a 30 year certificate can't be created from a parent that guarantees annual renewal and reverification.

Re:I've had the opposite experience.... (1)

Zapotek (1032314) | about 2 years ago | (#42469091)

Because all it would take to break through the auth (or whatever the SSL certs were used for) would be to mess with the system clock -- could be hard, could be easy, doesn't matter, it'd be one more liability.

Re:I've had the opposite experience.... (1)

TheGavster (774657) | about 2 years ago | (#42469141)

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:I've had the opposite experience.... (2)

Shimbo (100005) | about 2 years ago | (#42469181)

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:I've had the opposite experience.... (1)

complete loony (663508) | about 2 years ago | (#42470665)

My wife's PC once booted up in the year 62,012. Since every single ssl cert was out of date, from her point of view the entire internet was broken.

Re:I've had the opposite experience.... (1)

Anonymous Coward | about 2 years ago | (#42469969)

> why wouldn't you accept a cert that's before its validity period?

Because it is outside the validity period.

Bug not a feature. (0)

Anonymous Coward | about 2 years ago | (#42468479)

Normally, the obligatory "It's a bug not a feature" comment would be sarcasm.
 
As with most things apple, though ... there will be plenty of people who think it's genuine.

Edge Cases (0)

Anonymous Coward | about 2 years ago | (#42468483)

We test our edge and special cases pretty thoroughly, "beginning" and "end" of time, every DST spring/fall, and leap years/seconds.

Still have bugs though.

Simple... (1)

Synerg1y (2169962) | about 2 years ago | (#42468495)

Don't hard code dates, calculate them. If you have reference tables for date pair values, there needs to be a process in place to update those tables. Can't think of a whole lot more that can go wrong on a year change....

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

Anything else?

Re:Simple... (0)

Anonymous Coward | about 2 years ago | (#42468697)

On that point, don't store future datetimes in GMT. Store it in the Timezone local to the event and the TZ offset. We saw from the last time the government changed timezones that it became a huge massive clusterfuck because it was impossible to know if any given date had already been corrected for the change in GMT (and believe me, from the perspective of the human who is using your software, THEIR time did not change: their 10AM appointment should still be at 10AM).

Re:Simple... (1, Insightful)

Nerdfest (867930) | about 2 years ago | (#42469325)

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:Simple... (0)

Anonymous Coward | about 2 years ago | (#42470817)

Did you actually read the post you replied to?

Re:Simple... (1)

DavidRawling (864446) | about 2 years ago | (#42470919)

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:

  • Jan 27, 2013 03:00:00 UTC
  • Jul 15, 2013 16:00:00 UTC

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 with an associated original timezone, original timezone offset, and a last updated time. For some apps that could be overkill. For others, it might be necessary.

You need the timezone information so that you record the creator's intent - I set this to 10 am Thursday in my timezone because I want it to be at 10am. You need the last updated date/time so that you know what the timezone configuration was when it was updated (i.e. "it was created/changed in daylight saving time, so even though we're now NOT in DST, I need to do some extra correcting of the display").

TL:DR; time is harder than it seems.

Re:Simple... (1)

Nerdfest (867930) | about 2 years ago | (#42470997)

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 problems, including people creating data in one time zone and it being used in another.

2038 (3, Informative)

Dishwasha (125561) | about 2 years ago | (#42468505)

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:2038 (0)

Anonymous Coward | about 2 years ago | (#42469307)

Could it be spam, spam, spam, spam, spam, and spam?

Re:2038 (1)

rubycodez (864176) | about 2 years ago | (#42470667)

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

Time. . . (1)

smitty_one_each (243267) | about 2 years ago | (#42468565)

. . .is a Western disease.

Re:Time. . . (1)

rubycodez (864176) | about 2 years ago | (#42470677)

never been to Tokyo or Kuala Lumpur or Tapei? some asian societies take the concept of workaholic to the next level....

Unit Test? (1)

Threni (635302) | about 2 years ago | (#42468645)

What does this have to do with Unit Tests?

Re:Unit Test? (1)

Nerdfest (867930) | about 2 years ago | (#42469369)

Other than that fact that good unit tests would have caught this problem, not much.

Nope (1)

T.E.D. (34228) | about 2 years ago | (#42468649)

Seeing as I got an automated message castigating me for not filling out my electronic timesheet for 12/30 (a vacation day), and I heard tales of some folks getting a double paycheck and being asked to pay the extra back, I'm guessing the answer is no.

Re:Nope (1)

sconeu (64226) | about 2 years ago | (#42469649)

Not to mention that 30 Dec 2012 was a Sunday....

It's very simple... (1)

Anonymous Coward | about 2 years ago | (#42468651)

Points in time are *always* represented internally as seconds-since-epoch (or milliseconds, or whatever unit makes sense for your app). Calculations are always done on values which are seconds-since-epoch. The *only* time that a date is *ever* converted to a year/month/day hour:min:sec representation is strictly for display purposes.

Do this, and 99% of time-related bugs never occur. The problems with date-related logic almost always stem from some programmer thinking that they should carry a date around internally in a broken-out, human form - and that is always a mistake.

Very simple...but misses many common needs (3, Insightful)

DragonWriter (970822) | about 2 years ago | (#42468765)

Points in time are *always* represented internally as seconds-since-epoch (or milliseconds, or whatever unit makes sense for your app). Calculations are always done on values which are seconds-since-epoch. The *only* time that a date is *ever* converted to a year/month/day hour:min:sec representation is strictly for display purposes.

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:It's very simple... (0)

Anonymous Coward | about 2 years ago | (#42469881)

The *only* time that a date is *ever* converted to a year/month/day hour:min:sec representation is strictly for display purposes.

The real world uses dates in human form. The real world demands business logic that can identify the first day of the month or the last friday of the year, and if you say, "use a lookup table", someone is going to demand business logic that can automatically populate that table.

The *real* problem with date-related logic is programmers like you thinking there is a simple one-size-fits-all solution that they can implement themselves instead of doing it the proper way: using library functions. No matter how smart you think you are, you will get screwed trying to roll your own date handling.

Re:It's very simple... (1)

jc42 (318812) | about 2 years ago | (#42470637)

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 of my own - and send them my code. They've generally thanked me for the contribution, and sometimes said that they got some good laughs from my descriptions of the problems in our local library routines.

True naivetï½ is trusting code supplied by an organization whose primary motive is profit, not engineering quality.

Re:It's very simple... (0)

jc42 (318812) | about 2 years ago | (#42470813)

True naivetý is ...

Jeez; ya can't even get away with using a mot franÃais that's commonly used in English here. And we're talking about quality products ...

Seriously (1)

ozduo (2043408) | about 2 years ago | (#42468687)

we need an accurate method of identifying and solving these future bugs because they are playing havoc with my Tardis!

No (0)

Anonymous Coward | about 2 years ago | (#42468689)

Our software only needs time periods less than approx .2 seconds. And we have everything in Zulu and represented as tai64n. Converting to/from human readable time is not our problem

yes we do (0)

Anonymous Coward | about 2 years ago | (#42468703)

and daylight savings time is the worst idea ever!

Re:yes we do (1)

jc42 (318812) | about 2 years ago | (#42470883)

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

Certificate expiration (0)

Anonymous Coward | about 2 years ago | (#42468823)

My biggest fear is an expiring certificate ending civilization.

Outside of testing around DST boundaries I don't test for the future specifically. Past is prologue.

only relevant for license code (0)

Anonymous Coward | about 2 years ago | (#42468847)

Since I'm working on code that does not really care what day it is, this is a REALLY silly problem to worry about.
That is, if it is important to you, it means you are writing code which is GUARANTEED to fail to work sometime, based upon WHEN.

BTDT..... (0)

Anonymous Coward | about 2 years ago | (#42468853)

One of the features I had the (mis)fortune to develop dealt with future offsets, DST, and different timezones. I knew to test it. How does anyone not think to test DST and year-end rollover for a TIME app!?

Resume fodder (1)

user-hostile (1177051) | about 2 years ago | (#42468887)

Great. Now I can list "follows best practices of software giants such as Adobe and Apple" on my resume!

Residual Y2K Problem (0)

Anonymous Coward | about 2 years ago | (#42468927)

Commercial software is rife with forward date bugs. To deal with the Y2K problem many companies modified code to assume that any two digit year less than or equal to 50 was 1900s and any two digit year greater than 50 was 2000s. How many of those companies took the time and spent the money to go back and update their software to four digit years?

Re:Residual Y2K Problem (1)

LordStormes (1749242) | about 2 years ago | (#42469143)

How many people will be using a 50+ year old OS/app in 2050 when it would become a problem?

Re:Residual Y2K Problem (1)

Andrewkov (140579) | about 2 years ago | (#42470319)

Funny, that's exactly what we said in the 60's, 70's and 80's when we used 2 digit year codes to save space.

The bigger question, with a possibly scary answer: (0)

Anonymous Coward | about 2 years ago | (#42469045)

Why would a forward year matter in the first place? What kind of sloppy code is being written that can't cope with a simple change in the year?

I shudder to think...

one of these days (1)

hurfy (735314) | about 2 years ago | (#42469059)

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 on the HD alone and the 5 lb transformer on the CPU box are a little intimidating. Time sucks

Re:one of these days (1)

rubycodez (864176) | about 2 years ago | (#42470839)

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 (2)

LordStormes (1749242) | about 2 years ago | (#42469071)

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:Automated testing (0)

Anonymous Coward | about 2 years ago | (#42469335)

Wow. What's your solution for testing the test scripts? (CAPTCHA: multiply)

Re:Automated testing (0)

Anonymous Coward | about 2 years ago | (#42469585)

You're full of shit.

Dates are not hard! (1)

jackb_guppy (204733) | about 2 years ago | (#42469305)

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 the system. It is not hard, just need to be tested.

Why are these bad coders still in the system, that can't do the simple math let alone simple testing.

Re:Dates are not hard! (0)

Anonymous Coward | about 2 years ago | (#42470037)

Why are these bad coders still in the system, that can't do the simple math let alone simple testing.

Dates are hard because humans meddle with them. If you think otherwise, you are either inexperienced or a poor programmer. What date was the last Friday of 2011? In Samoa, it was Dec 23rd.

If you are rolling your own datetime math, you need to be taken out back and shot. Use a library.

Re:Dates are not hard! (0)

Anonymous Coward | about 2 years ago | (#42470183)

But the people that wrote the libraries have already been taken out back and shot.

Don't test - inspect (0)

Anonymous Coward | about 2 years ago | (#42469323)

Don't test. Inspect.

If you can't inspect, how do you plan to exit test?

http://www.mfagan.com/pdfs/ibmfagan.pdf

32-bit UNIX HAS A PROBLEM IN 2038++ (0)

Anonymous Coward | about 2 years ago | (#42469467)

There's a "date problem" for you, lol... -> http://en.wikipedia.org/wiki/Year_2038_problem [wikipedia.org]

* :)

APK

P.S.=> Let the 'flames' commence - Yes, there are "fixes" but do ALL 32-bit UNIX's employ them? I doubt it...

... apk

Re:32-bit UNIX HAS A PROBLEM IN 2038++ (1)

rubycodez (864176) | about 2 years ago | (#42470561)

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.

Correct on embedded, see link... apk (0)

Anonymous Coward | about 2 years ago | (#42470761)

It's part of WHY I posted it (brake systems especially) -> http://en.wikipedia.org/wiki/Year_2038_problem [wikipedia.org]

* VERY GOOD of you to note what you did though...

(Thanks much, on the tip on mySQL - as I had NO IDEA on that much!)

APK

P.S.=> Lastly - Do you have a link to that issue on mySQL? I'd appreciate it, & "TIA" (thanks-in-advance)...

... apk

Re:Correct on embedded, see link... apk (3, Informative)

rubycodez (864176) | about 2 years ago | (#42470995)

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>

"1 warning" - got ya... apk (0)

Anonymous Coward | about 2 years ago | (#42471089)

As good as required I suppose - good catch, & I *wish* I knew that back in a database class I took years ago that was implemented using mySQL in fact...

Would've knocked the prof. for a loop...

* Thank-You... your select query result does the rest!

(Would that also hold true on the 64-bit version of mySQL as well, since it IS 64-bit? Just curious...)

APK

P.S.=> I am assuming that is truthful here, & though I have the 64-bit version of mySQL downloaded here to test? I just have NO inclination (or energy tonite to be honest) to load it & test...

... apk

Intricacies of time (1)

plopez (54068) | about 2 years ago | (#42469621)

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]

Yes (1)

jtavares2 (652237) | about 2 years ago | (#42469671)

I test for all possible future dates.

Falsehood 35: (1)

John Hasler (414242) | about 2 years ago | (#42469971)

No one would be stupid enough to set the system clock to local time.

Bad Assumptions About Dates and Times (1)

swilly (24960) | about 2 years ago | (#42470351)

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 computer on the domain had the wrong time. The administrators of the domain controller didn't think this was a big deal, and things will fix themselves soon, so why bother adjusting our clock? Normally that would be fine, since the military has standardized on Zulu (GMT) since forever, and all military systems were required to store and transmit dates in that format. But there was one system, which I won't name, that used local time for its database and then asked Windows to convert to Zulu time for the XML data transfer. It took several days before we found out that every date and time we were given from them was a lie. This caused us all sorts of problems and fixing all of the dates was a major pain.

After all the complaints, the meetings with developers, and so on, we naturally thought that the developers for this system had gotten their act together and fixed their problem so we wouldn't see it again. Nope. Sure enough, in October we had the exact same problem, except this time I was watching for it and modified our insert into SQL Server to adjust the time. (I'm not a fan of putting a lot of business logic in stored procedures, but it really helped that time.) I made sure that my replacement was aware of the situation before the next change in April, but apparently they finally fixed their database by then.

What I learned is that databases should always use GMT and you should never ask the system for the local time and then convert to GMT, as it may lie. Instead ask the system for the GMT time.

Re:Bad Assumptions About Dates and Times (0)

Anonymous Coward | about 2 years ago | (#42470541)

Iraq didn't use daylight savings from 2008 onwards.
I guess that is one way to fix it.

Framemaker still exists? (1)

Ralph Spoilsport (673134) | about 2 years ago | (#42470387)

dayum. I haven't heard the word "framemaker" in like an aeon or two. I thought it bit the dust when Quark and InDesign took over.

personal favourite (0)

Anonymous Coward | about 2 years ago | (#42470573)

My personal favorite is that a time only happens once.
Alas it isn't true when the time goes back an hour for dst and you are foolish enough to store the time in local timezone.

Careful setting dates (1)

leighklotz (192300) | about 2 years ago | (#42471001)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?