back to article iPhones clock-blocked and crocked by setting date to Jan 1, 1970

Watch out: setting the time and date on an Apple iPhone, iPad or iPod to January 1, 1970, may brick the thing. In a Reddit discussion today, folks described how setting their device's clock back to that point in history resulted in a crash after which their iThing was unable to boot or be restored via iTunes. The bug affects …

  1. grumpyoldeyore
    Joke

    The 1970s...

    The decade that time and taste and Apple forgot....

    1. Anonymous Coward
      Anonymous Coward

      Re: The 1970s...

      Went into apple store and borked all display devices.

      I encourage others to do the same.

      I guess we could write an app that sets the clock too?

      1. Sokolik
        Happy

        Re: The 1970s...

        Yes, the spirit of the 1970's: rock-on! Good on ya.

      2. Ed 11

        Re: The 1970s...

        You, Sir, are a complete and utter tool.

    2. bazza Silver badge

      Re: The 1970s...

      I minor observation is that the at 00:00:00 01/01/1970 UTC, the local time in the UK was 00:01:00, for the UK was then on British Standard Time. Thus whilst PST then was 8 hours behind UTC, it was 9 hours behind London.

      Timezones are, and always have been, a nightmare.

      1. x 7

        Re: The 1970s...

        "I minor observation is that the at 00:00:00 01/01/1970 UTC, the local time in the UK was 00:01:00, for the UK was then on British Standard Time. "

        err.......no

        during the Standard time experiment we were an hour ahead, not a minute so the time was 01:00:00

        1. Danny 14

          Re: The 1970s...

          If a display model of anything lets you get to core settings then this will be the least of their issues.

          10 print "dave snogged alison"

          20 goto 10

        2. bazza Silver badge

          Re: The 1970s...

          err.......no

          during the Standard time experiment we were an hour ahead, not a minute so the time was 01:00:00

          My bad. Er, good to see someone was paying attention even if it wasn't me...

    3. Chris Parsons

      Re: The 1970s...

      Nope, the decade that gave us the late, great Charlie Gillett, Elvis Costello, Bees Make Honey, Roogalator...

      1. CrazyOldCatMan Silver badge

        Re: The 1970s...

        > the decade that gave us the late, great Charlie Gillett, Elvis Costello

        Genesis*, Yes*, Pink Floyd*, Jethro Tull* et. al.

        (* yes yes, I know that they officially came into existance in the 60's but they rose to promenance in the 70's..)

  2. Frank N. Stein

    Why would anyone set their iPhone's time to 1/1/1970 when clearly, that isn't the present date? Are we just looking for ways to crash iPhones so that we can report on how doing something most people would never do can crash an iPhone? Surely, there is something most people would normally do that might crash an iPhone?

    1. diodesign (Written by Reg staff) Silver badge

      Wonderful way to prank someone or an Apple store, I guess. You can also troll people into doing it...

      C.

      1. Syntax Error

        Don't see the "wonderful" part of doing this. Its the kind of thing a nasty dick head would do.

    2. goldcd

      Yes, that's pretty much it.

      It's a petty jab at Apple, but then as I'm reasonably sure somebody should have tested that it's impossible to brick a phone by entering anything into the settings menu, there's some justification for the ridicule.

      1. JeffyPoooh
        Pint

        Re: Yes, that's pretty much it.

        Somebody at Apple actually, literally, explicitly created a Set Date & Time menu that scrolls all the way back, back to a time decades before the iOS even existed.

        Dough-heads.

        1. brotherelf
          Trollface

          Re: Yes, that's pretty much it.

          Um, no. Somebody at Apple used the provided standard UI widget for date and time. (OTOH, if there's any company that could pull off "we're sorry you can't pick your date of birth on that web page, but we're using our standard widget which doesn't go back beyond (phone release year), it'd be Apple.)

          1. JeffyPoooh
            Pint

            Re: Yes, that's pretty much it.

            brotherelf "Somebody at Apple used the provided standard UI widget for date and time."

            Who provided the 'provided standard UI widget'?

            Apple. The widget must have BEGINNING and END range settings.

            Almost certainly, some dough-head typed in BEGINNING = 1970 etc. Because THEY DIDN'T THINK.

            No matter how you slice and dice it, it's an explicit and monumentally-dumb error.

        2. Dan 55 Silver badge

          Re: Yes, that's pretty much it.

          IIRC Nokias allowed the first of January of the OS's build year and only took time updates from the mobile network, yet calendar dates and birth dates could go back to 1/1/1900.

          Still so much to learn down there in Silly Valley. If only they learnt it before launching their perpetual beta OSes.

        3. anonymous boring coward Silver badge

          Re: Yes, that's pretty much it.

          I don't see any fault with implementing that.

          It's making the product future proof -in case we in the future can travel back to the 1970s.

        4. Wyrdness

          Re: Yes, that's pretty much it.

          And then forgot to test the edge-case.

    3. Christian Berger

      Well they run NTP

      Apple products today run NTP by default so they can enforce DRM. NTP is comparatively easily spoofed so you can just set the time for someone else.

    4. imaginarynumber

      Someone running iOS 9.3 beta 3 was trying to fix a bug that stops the time being displayed in the status bar at the top of the phone.

      It seems that he tried various dates and eventually scrolled back to 1/1/1970.

    5. Kraggy
      Thumb Down

      Yup, seems to be a case of someone looking for anything to slam Apple for.

      No, I'm not an Apple fanboi, I loathe some of their policies and attitudes but this is simply a pathetic attempt to find something to complain about.

      1. Lee D Silver badge

        This allows an NTP attack on almost any public wifi which permanently bricks your phone. All you have to do is supply DHCP time server responses to point to your own NTP server that sets the date to 1/1/1970. Or intercept the (plaintext) NTP request that it sends to ANY NTP server on your Wifi.

        That's NOT expected, or sensible, behaviour and provides a dangerous, and costly attack. Imagine doing that at a conference. Hundreds of people join the free Wifi and bam, their phones are bricked.

        This isn't a "non-issue". It shouldn't happen. As a school IT manager who's just sent the kids off for half-term with their 1:1 iPads (which are affected), this means I can expect at least half a dozen completely dead devices requiring Apple service (which we avoid like the plague) just because of a prank going round.

        You can't rely on devices with such bugs. Now this is one bug, a bug that requires some setup (it DOESN'T require much user co-operation, note, just joining a public Wifi!), so the chance is low. But the damage is high. Your phone is bricked until, basically, you take it back to Apple. Or restore from a backup in a certain way (let's hope you have recent backups of your phone, right?). That means the impact is high.

        So it's not "nothing". But it's certainly not the end of the world. However, for anyone managing Apple devices, or who doesn't want their phone to have to go back to an Apple store in order to ever work again, it's a huge pain in the butt.

        1. Colin Miller

          NTP rejects bogus times?

          Doesn't NTP, by default, reject anything that is more than 1000 seconds (about 20 mins) different that the current time?

          1. Anonymous Bullard

            Re: NTP rejects bogus times?

            Doesn't NTP, by default, reject anything that is more than 1000 seconds (about 20 mins) different that the current time?

            But what is the current time? If the device already knew that, then it wouldn't bother with NTP.

          2. Bucky 2

            Re: NTP rejects bogus times?

            I think it's important here to disambiguate the protocol NTP from the ntpd daemon offered by the folks at www.ntp.org.

            The ntpd daemon by default ignores time offsets that are huge. BUT it's also a common practice to do an ntpdate in the script that starts the daemon to set the hardware clock first. I think this is to handle wacky-ass BIOS clocks and make it so network time Just Works.

            The NTP daemon chronyd respects large offsets -- at least on startup (also I think during running, but I'm not as clear on that).

            Long story short, you can't rely on rejecting large offsets to protect you.

        2. This post has been deleted by its author

    6. King Jack

      Why would anyone set their iPhone's time to 1/1/1970

      As an easy way to find out what day is was on that date. I regularly use digital clocks/calendars to do that. It should NOT destroy anything.

      1. John Brown (no body) Silver badge
        Facepalm

        Re: Why would anyone set their iPhone's time to 1/1/1970

        "As an easy way to find out what day is was on that date. I regularly use digital clocks/calendars to do that. It should NOT destroy anything."

        Ok, so you've check what day it was on the 1st Jan 1970. Fine. Now why the fuck would you then set the OS clock to that date? The calender already tells you what you need.

        1. Dave 126 Silver badge

          Re: Why would anyone set their iPhone's time to 1/1/1970

          >This allows an NTP attack on almost any public wifi which permanently bricks your phone.

          Has this this been demonstrated in a proof-of-concept attack?

          1. Destroy All Monsters Silver badge

            Re: Why would anyone set their iPhone's time to 1/1/1970

            You should be able to set it to anything that the widget allows you to w/o ill effects.

            That basic design 101.

            End of line.

          2. Anonymous Coward
            Anonymous Coward

            Re: Why would anyone set their iPhone's time to 1/1/1970

            Not tried it on a public WiFi - just tried it on our Test WiFi though. Our NTP server would, as previously mentioned, not let the time deviate by more than 1000 seconds.

            So I commented out the pool servers so it only had the local IP of our NTP box, dropped the internet connection on the test network router just to be sure, set the system clock on the NTP box back to 1/1/1970 and then it went through fine and bricked one of our test iPhone 5C's.

            So concept proven.

    7. This post has been deleted by its author

  3. allthecoolshortnamesweretaken

    So the world according to Unix began on 1970-01-01*...

    Now all I need is an app to calculate the number of angels that can dance on the head of a pin.

    *Date format as defined per ISO 8601

    ( see https://xkcd.com/1179 )

    1. admiraljkb
      Coat

      "*Date format as defined per ISO 8601"

      and in this modern era, is there another date format other than for the non IT industry civvies? :)

      1. art guerrilla

        typing this on sat13feb2016, THE only unambiguous date format which -as you can see- can be run all together, and it is still EASILY readable FOR HUMANS...

        stupid computers ? not so much...

        1. Anonymous Coward
          Anonymous Coward

          No use internationally, assumes "Feb" and "Sat" means something to the human. Still whoever forked the date format between US mm/dd/yy and the rest of us should die in a fire

          1. Crazy Operations Guy

            " date format between US mm/dd/yy and the rest of us should die in a fire"

            Seconded. Which is why I write my dates as 13-Feb-2016. I'm an American, but its been over a decade since I last used our broken data format. Helps quite a bit when sending email to India since some places have started adopting the US data format, while others use the British format (hooray for outsourcing...)

            1. Fred Flintstone Gold badge

              Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

              I've used what I've known as the Japanese format for decades (which is what that ISO seems to refer to), because YY(YY)MMDD also happens to sort nicely along date lines. It's such a simple thing it's amazing it wasn't adopted globally.

              I must admit I have found the US format exceptionally pointless. Does anyone have an idea what drove the adoption of that format? I mean, I can accept being blind drunk as an explanation, but I struggle to come up with a rationale for this as a deliberate choice :).

              1. This post has been deleted by its author

              2. Barry Rueger

                Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                Yes! Anything that goes through many versions on my computer gets named 2016_02_14_filename.txt.

                1. DN4

                  Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                  > Anything that goes through many versions on my computer gets named 2016_02_14_filename.txt.

                  In mine it is stored in a revision control system...

                2. Anonymous Coward
                  Anonymous Coward

                  Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                  Yes! Anything that goes through many versions on my computer gets named 2016_02_14_filename.txt.

                  All of it? Isn't that going to get awkward tomorrow when the date changes?

                  :)

              3. heyrick Silver badge

                Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                Yup. YYYY/MM/DD. When people at work comment on the date format using words like weird" and say that nobody uses such a date format, I point to the photos printed and stuck on the wall in quality control. The camera burns in the date in exactly that format. And given the company deals with international clients some of whom use American dates and some who use European dates (and the ensuing ambiguities), I think the big endian format makes sense.

                So. Have an upvote.

                1. anonymous boring coward Silver badge

                  Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                  The Swedish standard is YYMMDD with no slashes.

                  Simple, sortable, and extremely quick to read.

                  YYYYMMDD cam also be used.

                  1. This post has been deleted by its author

              4. This post has been deleted by its author

              5. Anonymous Coward
                Anonymous Coward

                Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                I believe it follows the formal writing format for dates.

                Eg. Sunday, February 14 2016 = 2/14/2016

                I suspect mm/dd/yy is an accepted abbreviated form of the date in writing and us Americans are too lazy to use different formats in non-writing situations.

                1. x 7

                  Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                  "Eg. Sunday, February 14 2016 = 2/14/2016"

                  probably not.....in the UK that would be "14th February 2016"

              6. Steven Roper

                Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

                I also use YYYYMMDD ordering for dates, since matches numerical with chronological file sorting. I avoid DDMMYYYY or MMDDYYYY like the plague simply because for the first 12 days in any month it becomes impossible to distinguish between US and normal date formats. I've had some really nasty errors crop up because some American customer provided 7/1/2007 as a payment date and my system parsed it as 7th of January instead of the 1st of July as intended (1st July is the first day of the financial year in Australia.)

                To the point where, when I design ecommerce websites, all dates on orders, invoices, transactions etc, are displayed in YYYY-MM-DD hh:mm:ss format by default; the customer can change the date format if they wish (since the board insisted on providng the ability), but I've buried the date-format control so deeply in the CMS and made it such an utter bitch to do so, that most people simply give up trying and accept the sensible format. So my crusade to make the world adopt the logical year-first convention is coming on apace!

            2. el_oscuro

              Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

              13-Feb-2016 is the date format that both the US military and Oracle use.

            3. Queasy Rider

              Re: " date format between US mm/dd/yy and the rest of us should die in a fire"

              Agreed, so I always respond to the request, "Date of birth?" with "April first", never four-one or one-four, and also I date written documents the same way unless the the form specifies otherwise.

              The dating confusion once gained me five months on a warranty repair though when I presented my original Walkman (remember them?) for repair and the repair shop interpreted the sales slip date opposite to its original meaning, month/day vs day/month.

        2. Anonymous Coward
          Anonymous Coward

          You don't think a computer could be made to parse "sat13feb2016" and all variations thereof?

          He he.

    2. Doctor Syntax Silver badge

      "So the world according to Unix began on 1970-01-01"

      Not at all. The folks who developed Unix knew about negative numbers. The cal command command, for instance, will calculate calendars for dates much earlier than that. Try cal 1752

      They were an erudite lot (more erudite than VCs it seems). man cal in V7 Unix listed as a bug that taking Jan 1 as the beginning of the year was historically naive.

      1. Anonymous Coward
        Anonymous Coward

        taking Jan 1 as the beginning of the year was historically naive.

        Not just an historical curiosity. The Government has not yet noticed that the year no longer starts at the First Point in Aries, currently around April 5th due to the accumulated errors prior to adopting the Gregorian Calendar. At least it makes accountancy software that handles wages that little bit more complicated and expensive.

        1. Doctor Syntax Silver badge

          Re: taking Jan 1 as the beginning of the year was historically naive.

          It's a fairly complicated set of events. "Years" can start at different dates. Academic years (at least in the UK), for instance, start with the Autumn or Michaelmas (YMMV) term. The church's year started on the assumed date of Christ's conception, 9 months back from Christmas, i.e. March 25, Lady Day. That also became the starting date for a lot of commercial arrangements. However there was also a tradition that January 1st was the start of the year so you may well find dates in the first few weeks of the year being given along the lines of 1722/3. I know of one published early C18th diary which starts years in January and some years are labelled in that fashion and some in modern fashion.

          England and colonies stuck to the Julian calendar long after many countries had gone over to the Gregorian (but not all at the same time) and by 1752 the two calendars were 11 days out of sync. This was solved by omitting 11 days from September so the calendar for the start of that month reads 1 2 14 15 16 and January 1st was set as the start of the year in accordance with the Gregorian calendar.

          This introduced a potential problem with contracts. That was solved by having the contracts which covered that period run for the appropriate number of days. So a contract taken out on March 25 in 1752 would expire on April 4th 1753 and a new contract would start on April 5th. The "loss" of 11 days was problematic in itself so it's not surprising that nobody wanted to tinker with changing contract terms as part of the legislation. On the basis of not fixing what wasn't broken, nobody has tinkered with it since so the UK financial year still runs from April 5th - and try to visualise the complications and expense it would cause to change that now.

          Of course businesses are free to arrange their accounting years whenever they like and if a business thinks it's a good idea to go through the accounting year turnover when everyone's feeling a little under the weather, good luck to them.

  4. Andrew Jones 2

    One would hope that setting up a nefarious NTP server would not in fact work - because good NTP clients generally refuse to change to the date and time supplied by an NTP server that would require a change across days and most that I have seen won't even change if the time is more than a few hours away from the currently set time.

    1. Anonymous Coward
      Anonymous Coward

      You could spoof an NTP server within a WI-Fi network and trigger any devices seeking a time update to receive your spoofed date and time. That's one of the key flaws here.

      1. Andrew Jones 2

        Yes I saw what the flaw was - my point was that well designed NTP Clients would reject the spoofed time - because really good ones refuse timestamps that are more than about 2 hours from currently set time and most will reject timestamps that are more than 24 hours different to the currently set time. So providing that Apple coded the NTP client correctly - the phones should simply ignore any attempts to respond to an NTP request with a response of "0" (Though having said - whether the phone tries to resolve the timestamp after timezone conversion before rejecting it - thus potentially triggering a crash is an unknown at this point)

        1. raving angry loony

          Isn't "providing that Apple coded the NTP client correctly" equivalent to saying "providing that Apple coded their clock client correctly"? Which they evidently have NOT.

          Edge conditions aren't just for show, they're a standard test in any self-respecting test suite. If they have such grievous consequences to something so mind-stunningling simple to prevent, what the fuck else have they left in their code waiting to bite the helpless Apple iConsumer?

        2. Blank Reg

          Given the iPhone's repeated problems with times and alarms I wouldn't bet much on them having a robust NTP client

        3. TeeCee Gold badge
          Meh

          Except that most consumer devices will set the date and time themselves when first powered on OOB[1] by the grinning monkey that bought them. What they have at that point is, more often than not, more than 24 hours out from current.....

          [1] A "must have" feature, unless you are prepared to hire a shitload of call centre staff who all have the patience of Job and an infinite supply of Ritalin within easy reach.

        4. Anonymous Coward
          Anonymous Coward

          "more than about 2 hours from currently set time"

          Yes, but how often? If the server can change the client's time by 2 hours every 10 seconds... then it can take it back to 1970 in about 3 weeks...

        5. heyrick Silver badge
          Facepalm

          because really good ones

          There's your problem right there.

          We're talking about an OS that didn't apply saturating maths to the timezone subtraction (or, at least, bounds check it before blindly knocking off X hours) so what is the confidence that the NTP client is any good?

          Also - why is this bricking iOS? Shouldn't it just think the date is 2106? Or are they still using signed integers for the date (and choking on negative dates - another bounds check fail)? Because, you know, 2038 is soooooo far away that it can be ignored for another two decades.

  5. Anonymous Coward
    FAIL

    You are holding the epoch wrong!

    Magical and game-changing

    1. Chemist

      Re: You are holding the epoch wrong!

      "You are holding the epoch wrong!"

      I think you mean the iPoch ®

  6. 45RPM Silver badge

    Testing is a thankless task. It's dull, it's repetitive, and it's not as glamorous as coding. So it isn't surprising that bugs like this sneak through in anyone's software (Apple's, Microsoft's, Google's, yours, mine)

    It needn't be this way though. Automated testing, with intelligently designed scripts, can take care of all the boring repetitive tasks of ensuring that every function works the way that it is supposed to and regression testing. Those tests can be left running every night.

    This frees up a lot of human tester time, not for redundancy (before all the accountants get excited) but to do the vital, interesting, and often overlooked task of what I like to think of as vandalism.

    Vandalism is interesting testing because it's devious. It's imaginative. It doesn't concern itself with whether the software works as designed (the automated testing and UAT will take care of that). All it does is try to smash the software, crash it, break it by any means. And once a good exploit has been found, of course, it gets added to the test automation suite - and the tester goes back to be deviously destructive again.

    I imagine that most of the big software companies do this already - but perhaps they should do it more. And I might point out that before you snigger too much at the 'notorious wobbliness' of Apple software, bugs like this are everywhere. Yes. Even in your own preferred OS.

    1. Fruit and Nutcase Silver badge
      Joke

      Testing

      Testing is a thankless task. It's dull, it's repetitive, and it's not as glamorous as coding

      What Testing needs is something like what CSI has done to Forensic Science.

      Then again, better not

      The last thing Software Testing needs is what CSI has done to the perception and expectation of Forensic Science, by Joe Public

    2. Richard 12 Silver badge

      I'm reasonably sure they don't

      There are a lot of bugs in "big software" that automatic regression testing should have found.

      It also seems to be quite difficult to get good testers in general - it seems like many just want to follow The Procedure and do nothing else.

      Which rather crushes the enthusiasm of the ones who don't.

      1. Tom 7

        Re: I'm reasonably sure they don't

        It is difficult to think up ways of crapping on software when you think you've spent a while building it - always best to get someone who doesnt know what they are meant to be doing - I remember blowing up a piece of bulletproof code in 1983 or so that we were going to pay £1/4 million for because we forgot they were coming to demo it until the day before and had to scramble to get something together for them to demonstrate how good it was on our stuff.

        I used to write automated scripts to wander around the code libraries and throw random shit at them and see what happened - this modern stuff can be a bit difficult to do that with but you can often add an interface type layer specifically for accepting random shit.

        And always remember running in a debugger solves almost all code defects so make your live code launch itself in the debugger.

    3. Ken Moorhouse Silver badge

      Re: Vandalism

      Spot-on. It is impossible to test for every eventuality, of course, but yes, add to the test-suite once found. This is like the Y2K problem in reverse. A few other things I remember causing glitches:

      Errors in software calculating Daylight Saving correctly; Leap Year calculations in non-contentious leap-year cases where March 1st came a day early. Spreadsheets using a different epoch start point. I can imagine shed-loads of problems at the other end of the Unix epoch (in a mere 22 years time).

      1. Anonymous Coward
        Anonymous Coward

        Re: Vandalism

        Test max int, test min int?

        Is that too much to ask?

    4. Blank Reg

      I've worked in QA at very large software companies, and the key is to treat QA as a first rate engineering task, not an afterthought.

      That means not just hiring interns and programmers that weren't good enough for the dev team. You need experienced, talented programmers writing tests, but not the same programmers that wrote the code. Those programmers are the ones that never thought of the problematic conditions in the first place, it's unlikely they will think it them when they write the tests,

      1. MD Rackham

        > You need experienced, talented programmers writing tests

        Yes. But at most places I've worked you would also need to an "and cheap" to that list of qualities.

        QA is a great place to not only cut personnel costs, but the testing period is a great place to steal schedule time from when the developers run late (again). Or so I'm informed by various MBAs.

    5. John Brown (no body) Silver badge

      "Testing is a thankless task. It's dull, it's repetitive, and it's not as glamorous as coding."

      That's no excuse. It just means they are hiring the wrong people.

      There's plenty of people who do "thankless" and "repetitive" jobs but who still take pride in doing the job properly and well. Not everyone wants to be a high flyer living on adrenalin, they just want a quiet life, enough money to be comfortable and maybe a decent holiday or two each year.

      It's equivalent (probably related) to fight or flight response. Not only are people spread across the spectrum from one end to other but the world needs to operate that way.

    6. jake Silver badge

      It's not called "vandalism" ...

      ... it's called "destructive testing". My favorite game, hardware and code.[0]

      [0] There is no such thing as software ... Software is merely the state of the hardware ...

      1. Anonymous Coward
        Anonymous Coward

        Re: It's not called "vandalism" ...

        I'll upvote that, but I'll take it a step further...

        There is no such thing as hardware, it is merely the arrangement implied by the software.

      2. Destroy All Monsters Silver badge
        Headmaster

        Re: It's not called "vandalism" ...

        Software is merely the state of the hardware ...

        LOLNO.

        That's like saying mathematics is just the state of arithmetics.

        Software is not even bound to any hardware.

        1. jake Silver badge

          @DAM (was:Re: It's not called "vandalism" ...)

          Hardware is inert. Code wakes up hardware. Software is the ephemeral result.

          "Software is not even bound to any hardware."

          ITYM "code is not bound to hardware" ...

  7. Anonymous IV
    Happy

    Microsoft a decade ahead of Apple

    The beginning of time for the MS-DOS FAT file system was 1st January 1980.

    Which clearly shows something or other...

    1. Anonymous Coward
      Anonymous Coward

      Re: Microsoft a decade ahead of Apple

      For VAX/VMS it was the midnight preceding November 17, 1858. Maybe that's why Digital Equipment Corporation aren't around anymore.

      1. Phil O'Sophical Silver badge

        Re: Microsoft a decade ahead of Apple

        At least DEC used a standard (that's the Smithsonian's base date) and didn't just pull a random number out of the air. VMS will also still be going strong long after 2038, when other 32-bit OSes will overflow into negative time.

        1. Doctor Syntax Silver badge

          Re: Microsoft a decade ahead of Apple

          "At least DEC used a standard (that's the Smithsonian's base date) and didn't just pull a random number out of the air"

          Julian Day 2400000 no better or worse than any other arbitrarily chosen round number.

      2. Mike 16

        Re: Microsoft a decade ahead of Apple

        At least most of the world that was allowed to buy Vaxen would have been on the same calendar by then.

        http://www.skip.net/DEC/HP-OpenVMSsystems-Y2K-SPR.htm

        Of course, the Russians came late to the party, but they were not able to use Vaxen, unless of course they built their own, or "laundered" them through various "allies" of the U.S.

    2. Arthur the cat Silver badge

      Re: Microsoft a decade ahead of Apple

      Microsoft a decade behind Apple

      T,FTFY

    3. Anonymous Coward
      Anonymous Coward

      Re: Microsoft a decade ahead of Apple

      MS-DOS had a time resolution of 2 seconds.

      1. Anonymous IV

        Re: Microsoft a decade ahead of Apple

        > MS-DOS had a time resolution of 2 seconds.

        Well, the FAT file system certainly did, but not MS-DOS itself.

        "A time resolution of two seconds should be enough for anyone..."

  8. What? Me worry?
    Trollface

    iPhone end days cometh?

    Anyone ventured to try entering 19th January 2038?

    1. Havin_it
      Mushroom

      Re: iPhone end days cometh?

      Given it's a 64-bit OS you'd bloody hope they've used a 64-bit int for this. Then again... um, you first.

    2. jake Silver badge

      @What? Me worry? (was: Re: iPhone end days cometh?)

      Do you really think anyone using an iFad thinks beyond 22 months, much less 22 years? In my estimation, most iFad users can't think past 6 months ...

  9. Anonymous Coward
    Anonymous Coward

    Original code for this is to be autioned off?

    Obviously, the code found and written on the back of a fag packet.

    It is really Time to pension off that code writing dancing gorilla that blagged its way into the company claiming calendar skills!

    1. John Brown (no body) Silver badge

      Re: Original code for this is to be autioned off?

      "dancing gorilla "

      I thought he worked fro MS then went off to play with the sports teams he bought? Apple have one too?

  10. alpine

    WoW!

    "your timezone could pull you into negative time"

    Apple lead the way again, the first phones to time warp. And the space time continuum has curved corners. No one has ever surpassed their innovative minds. Their 'Joney' deserves another knighthood for his second piece of brilliance.

    1. Havin_it
      Trollface

      Re: WoW!

      >Their 'Joney' deserves another knighthood for his second piece of brilliance.

      Does that make Steve Jobs their 'Chachi'?

      ♫ Charles in charge, of our days, and our nights .... ♫

  11. Nixinkome

    Time took a cigarette.

    What does the Apple Watch say about this rhetorically?

  12. jake Silver badge

    Testing boundary conditions ...

    ... Not only a good idea, it should be the law.

  13. Donkey Molestor X

    oh noes my ZUNE got bricked by the leap year!!!!!

    wait a minute... this is an iphone?

    2038 can't come soon enough

  14. BurnT'offering

    This also how

    you can kill a Terminator

  15. theOtherJT Silver badge

    No excuse for this.

    I love the people trying to defend this one with "Well, we never thought anyone would do that? Why would anyone do that?"

    I'm sorry, you give an end user the ability to enter a value into ANYTHING you fucking sanitize that value before saving it somewhere. Users are untrustworthy bastards who will deliberately break things!

    1. Mike 16

      Re: No excuse for this.

      I expect that there was code to sanitize the input. It's just that the person who wrote it didn't have an accurate mental model of what "time" meant. Checking that the _local_ (entered) time is within some range is not sufficient. Those of us old enough to have lived through the Y2K scare can probably remember the amount of utter horseshit "solutions" proposed by various pundits. Apologies for the flashbacks if you are one of us. Real (robust) programming requires both real programming chops _and_ domain knowledge. Sadly, many corporations try to minimize the connection between the two.

      Time to review https://www.youtube.com/watch?v=-5wpm-gesOY

      It's a tough job, but somebody has to do it. IIRC, the last Y2K patch for WinNT came out in something like November 1999. And if you want to get entangled if a scary set of cracker-barrel tales, look into whether 1900 was a leap year, and what that did to people moving spreadsheets with historical data between DOS and MacOS versions of Excell.

  16. MD Rackham

    Kids these days...

    And to think my very first (paid) programming job was working on the "Date 74" project on a PDP-10 where all dates were going to roll over in 1974. Seems that TOPS-10 only allowed a 12-bit field for "days since 1962" in the file system.

    It's fuzzy, but as I recall they stole some bits from some other field which allowed an extension to some time in the 1990s, by which time *surely* no one would still be using the system. Hah! It wasn't Compuserve's only problem, but it was one more nail in the coffin.

  17. Anonymous Coward
    Anonymous Coward

    We'll know what next week is going to look like..

    Sigh. I know what the Net is going to look like next week, masses of spam and fake iOS advice to "fix" something or allusions to "settings that Apple wants to keep secret", all hoping to con innocent end users into setting iOS devices to Jan 1st 1970.

    It's not funny for those users and those who need to help them :(.

    1. Dan 55 Silver badge

      Re: We'll know what next week is going to look like..

      But why oh why do they get caught out every damn year?

      Setting the date wrong, dunking it in water, sticking it in the microwave...

  18. Mage Silver badge
    FAIL

    If the Phone Network time ...

    What if the phone company accidentally sets their server used to push mobile phone time?

    If a Phone company messes up their Solaris / Unix / Linux server the automatic network time is 1st Jan 1970, cue ALL iPhones with vulnerable iOS falling over?

    1. Mage Silver badge

      Re: If the Phone Network time ...

      I don't think the mobile time is NTP? Because dumb phones with no TCP/IP can have clock set by the Mobile Network Provider.

      1. Richard 12 Silver badge

        Re: If the Phone Network time ...

        It's not NTP.

        Not sure what it is, but it also includes timezone data.

        Been on one ship that had a set of not-yet-properly configured femto-cells, and it confused the heck out of my phone.

        It could get five hours ahead simply by walking through the ship!

  19. Anonymous Coward
    Anonymous Coward

    Is it another 3rd Party Repair Boobytrap?

    Wondering if it could have been added to 'thwart' against non-Apple third party repairs.

    A sort of trip wire/boobytrap for iPhones / iPad that had their battery replaced and/or circuit board replaced or modified. By disconnecting the main battery and say leaving the circuit board without power (in a storage tray etc) for a while when powering up again, the i-device would probably reset the clock to 01/01/1970.

    There seems more to this than meet the eye, may not be a coding 'mistake', but a sneeky move to force repairs to be carried out by Apple rather than a third party, by bricking the circuit board in such a set of circumstances, when a third party repaired the device.

    This might be another one of those 'its a feature' to protect consumers again.

  20. This post has been deleted by its author

  21. Anonymous Coward
    Anonymous Coward

    It's not just Apple...

    The VodaZap pager that I still use for production support won't recognise years after 2014. It's currently displaying 02/13/96.

    I guess they thought pagers would be long gone by now, a bit like all that software that got changed for AD2K with the cunning "if the two-digit year is less than 27 then it's the 21st century, else it's the 20th" trick. I'm sure it will all have been decommissioned by then...

  22. Mikel

    Another way to render an iPhone inoperable

    If you go to the settings menu, adjust time, and then drop an 8 pound sledgehammer on it.

  23. Anonymous Coward
    Anonymous Coward

    Another way to render a Nokia Lumia inoperable.

    Just install an early Windows 10 Mobile Beta, or even easier, just allow Microsoft Marketing loose on a decent bit of engineered hardware, it will be inoperable in no time.

  24. Anonymous Coward
    Anonymous Coward

    I can remember 1st Jan 1970

    It looked NOTHING like today!

  25. DeathStation 9000
    Devil

    It's almost certainly not a negative problem, and probably a zero problem. time_t is 64 bits on OSX, and most UNIX and UNIX-like systems are very happy with negative numbers. Or at least they are in the C libraries, unless it is some new-fangled nonsense they're using:

    time_t t = -10;

    printf("%zu\n", sizeof t);

    printf("%s", ctime(&t));

    Gives this in UTC land:

    8

    Wed Dec 31 23:59:50 1969

  26. DrM
    FAIL

    Don't be so negative

    Hey now, negative numbers can be a real challenge for the professional code-righter. I mean, you use them and you get yet another negative number. Perhaps rather than constantly having to write code that can handle rare occurrences like negative numbers, we should just ban their use?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like