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});
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; }
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);+ # Great news everybody! As of iOS 11, the date is now the number of
+ #
+ $date /= 1000000000 if ($date > 100000000000000000);
+
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; }
Part of me is sad they didn't pick 2007-01-09T09:41-08 as their epoch for maximal obnoxiousness and eye rolling.
What happened then?
First I expected it to be when Jobs died, but that was in 2011. Then I thought release of the first iPhone which was in 2007, but it was release in June. Maybe announcement of the iPhone? Yep: "On January 9, 2007, Steve Jobs announced iPhone at the Macworld convention, receiving substantial media attention."
"On January 9, 2007, Steve Jobs announced iPhone at the Macworld convention", and it was at 09:41 PST.
I'm sad that I didn't make the connection - back when Apple events were mindblowingly amazing… I fondly remember the rumor mill and the excitement leading up to it.
Whut?
BUT WHY?
They probably thought the high order bits weren't getting enough exercise after the switch to 64 bit.
i mean, it doesn't matter, but that conversion factor is for nanoseconds, not milliseconds.
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.
So, jwz, why not just give up and join the Android side? We have snacks!
Because the Android UI feels like it was designed by a committee of Linux kernel developers. Which in fact it turned out to be.
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.
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.
Unicode Character 'REVERSED HAND WITH MIDDLE FINGER EXTENDED' (U+1F595) 🖕
"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)
If you think you refuted rather than confirmed my statement, "our guidelines mean exactly fuck-all", you are mistaken.
whatever
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.
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.
Eldritch Java Shims of Horror is opening for Gurgling Fetid Madness this Friday!
I think I would watch that. Or not. I can't figure out what genre they would be…
I don't know. Is "the muffled, maddening beating of vile drums and thin, monotonous whining of accursed flutes" a genre?
Sign me up!
Your characterization is colorful, but overly generous.
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.
Ooh I forgot one! You get to use Chrome instead of
the new IESafari.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!"
You know, I think you hit the nail on the head…
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.
Your Prof. Farnsworth impression is really coming on:
It is definitely a suppository.
2001 is the epoch in Apple's Foundation APIs:
https://developer.apple.com/documentation/foundation/nsdate?language=objc
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.
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…
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.
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.