Epic Epoch Fail Redux

FFS, Apple.

diff --git a/hacks/sms-backup-iphone.pl b/hacks/sms-backup-iphone.pl
index 33c57c5c2..dabe9bbe6 100755
--- a/hacks/sms-backup-iphone.pl
+++ b/hacks/sms-backup-iphone.pl
@@ -241,16 +241,21 @@ sub sms_backup_1($$) {

SMSes use normal Unix time_t, with epoch = Jan 1, 1970 GMT.
iMessages use epoch = Jan 1, 2001 GMT.  WTF!
The "service" field is either 'iMessage' or 'SMS', but if it is set
at all, then that means the date is of the other epoch.
     $imsgp = 1 if defined ($h->{service});
+    #
Great news everybody! As of iOS 11, the date is now the number of
+    #
milli nano! nanoseconds since the Satanic Anti-Epoch of Jan 1 2001:
+    $date /= 1000000000 if ($date > 100000000000000000);
     $date += 978307200 if ($imsgp);

     my @lt = localtime($date);
     print STDERR "$progname: IMPROBABLE YEAR: " . localtime($date) . "\n"
       if ($lt[5] < (2005 - 1900) || $lt[5] > (localtime)[5]);

     if ($subj && $text) { $text = "$subj\n$text"; }
     elsif ($subj && !$text) { $text = $subj; }

Previously, previously.

Tags: , , , ,

39 Responses:

  1. David Hoover says:

    Part of me is sad they didn't pick 2007-01-09T09:41-08 as their epoch for maximal obnoxiousness and eye rolling.

    • Chris Davies says:

      They probably thought the high order bits weren't getting enough exercise after the switch to 64 bit.

  2. mike says:

    i mean, it doesn't matter, but that conversion factor is for nanoseconds, not milliseconds.

    • jwz says:

      But that means this SQL database is totally future-proof! Once it's storing every pair of bits on the polarization and spin of individual photons, I will still be able to properly sort my incoming text messages even when they are arriving at the speed of goddamned light.

  3. Wout says:

    So, jwz, why not just give up and join the Android side? We have snacks!

    • jwz says:

      Because the Android UI feels like it was designed by a committee of Linux kernel developers. Which in fact it turned out to be.

      • Wout says:

        Sure, it definitely used to be, but with the Material UI thing they paid actual designers.

        The UI is ok - Apple even decided that the back button was useful enough to give up part of the title bar in many apps.

        Plus it is way more configurable than iOS - you can use your own launcher, have widgets, live backgrounds, apps can configure global swiping actions, you can communicate over Bluetooth with Non-Apple-Sanctioned Devices, you can look at the cpu tasks… There's so much more of the pocket computer that you can use vs what Apple lets you do.

        Other things I enjoyed years before Apple saw fit to include them: AMOLED, Qi charging, water proofing, custom keyboards, NFC, more I'm sure.

        On the sad side, the apps are written in Java.

        • jwz says:

          Plus it is way more configurable

          Yeah... see also, "designed by a committee of Linux kernel developers."

          When it comes to UI, "configurable" typically means, "We couldn't take a fucking stand, so we just gave you a busy-box of options instead of an appliance that just fucking works."

          I don't want to configure my swiping options, thanks. I want someone to have taken the time to have just figured that shit out and done the integration testing.

          • > When it comes to UI, "configurable" typically means, "We couldn't take a fucking stand, so we just gave you a busy-box of options instead of an appliance that just fucking works."

            uhm... no, that's pretty much wrong - Android Guidelines are pretty much as clear and strict as the iOS ones. The Play Store doesn't enforce them as hard as iOS Appstore does - but that doesn't mean they aren't there.

            The old Android-Versions had many problems that lead to this reputation (and rightfully so - i.e. people never understood that their phone had a "menu button", much less what it did) but that has been many years ago.

            Beeing an iOS-Developer for money reasons I still think Android UI-Development is by far superior.

            • jwz says:

              uhm... no, that's pretty much wrong

              Unicode Character 'REVERSED HAND WITH MIDDLE FINGER EXTENDED' (U+1F595) 🖕

              The Play Store doesn't enforce them

              "Our guidelines mean exactly fuck-all"

              • > "Our guidelines mean exactly fuck-all"

                yeah - right

                because enforcing that would help with anything. Because we all know how there is no other way to install stuff on Android than the Play Store.

                Heck there's a whole lot of cheap devices that don't even come with the play store bundled.

                And then there's the part where Android Studio itself comes with all these things as default and you have actively to make an effort to bend your app to something that doesn't conform to those guidelines.

                I'd say it's pretty much an non-issue. (and you don't see many new non-confirming apps anymore)

              • anon3494 says:

                I find Android apologists to be the absolute worst.

        • > On the sad side, the apps are written in Java

          don't have to (native compilation of "anything" is fine, but UI-API comes mostly just with Java, also there is Kotlin and things like RAD Studio that compile to native binaries on both sides and use OpenGL to draw own GUI-Stuff) - but yes, most are Java and will continue to be for some more years.

          • jwz says:

            Let me point out that the xscreensaver Android port involves compiling C code with eldritch Java shims of horror, so I have been down that dark path and please don't try and tell me how using anything but Java on Android is "supported" or in any way anything other than gurgling fetid madness.

            And I built Lisp systems so I know from foreign function interfaces. Android is god damned Azazoth.

            • that's exactly why I said that you will want to use Java (or Kotlin) if you want to use the Android UI.

              Doesn't mean that beeing able to "just compile" your binaries for things that don't need that isn't a thing. (Syncthing would be an example - there is a Java-GUI-Project to controll syncthing and bundles the main binary, but this main part of the App is just the same as on Linux/Windows/Whatever and is accessed via http)

              And of course there's games and the RAD Studio stuff that each don't need Access to the Android Gui either.

            • lt says:

              Eldritch Java Shims of Horror is opening for Gurgling Fetid Madness this Friday!

            • anon3494 says:

              Your characterization is colorful, but overly generous.

        • MattyJ says:

          You can also get on unlimited advertiser's hit lists. Be a good consumer! Your privacy is worth nothing.

          You'll also have to test your app on dozens of combinations of hardware and Android versions since each carrier/phone can have anything they want installed on it. Fun! Versatile!

          I guess the one good thing about Android phones is that you don't have to worry so much about being mugged for your phone.

        • Wout says:

          Ooh I forgot one! You get to use Chrome instead of the new IE Safari.

  4. Glaurung says:

    Having made the switch to 64 bit timekeeping in order to avoid any future epoch problems, the programmer thought to themselves, "gosh, so many of those bits are just sitting there unused, and will never be used before the heat death of the universe! I know, we'll just switch to nanosecond precision, that will let more of those bits be useful!"

    • Wout says:

      You know, I think you hit the nail on the head…

    • thielges says:

      It is well known that unexercised logic atrophies over time resulting in weak, slow processing. People think Moore's law is responsible for modern computers being faster. But no, just the opposite is occurring, older computers are just getting beer bellies and flabby arms causing a relative difference in performance mistaken as generational improvement.

      We should applaud Apple's bold move to retain performance and halt the cycle of early obscelence. Once you upgrade to IOS 11 you'll never need to buy another phone.

  5. Derpatron9000 says:

    Your Prof. Farnsworth impression is really coming on:

  6. mdhughes says:

    2001 is the epoch in Apple's Foundation APIs:

    Apple is its own little universe. Classic Mac OS used Jan 1, 1904 as the epoch. The weird part is that they ever supported the Unix epoch beyond -timeIntervalSince1970.

    • Wout says:

      According to Wikipedia, 2001 was picked because it was the release year of OS X.

      Using iUT (iPhone Unveiling Time) doesn't seem so far-fetched anymore…

    • Chris Davies says:

      Fun fact, Symbian and EPOC before it used milliseconds since January 1st in the year zero, even when it was running on 16 bit hardware.

      When you've got 64 bits of storage to throw around, why limit yourself to never being able to represent dates earlier than 2001? At least UNIX had the "excuse" that 32 bits of storage seemed extravagant back in the day. Apple's decision is either stupidity or extreme arrogance, or possibly both.

      • ejelly says:

        You understand how signed integers work? And I would guess that having a close epoch would cause developers that don't understand them to realize how they work a bit sooner than, say, a 1970 epoch, when finally some over 47 year old geriatric enters their birthday.

        But in all seriousness, there's not really any difference to the UNIX epoch in terms of representable dates.