Hacker News Reader

Hacker News

Comment by mjmsmith | Hacker News Reader

Parent Full thread

mjmsmith

Yep, this was my iPad after I had a broken screen replaced: http://blog.marksmith.org/too-much-security/

I had to reinstall from a backup to enable wifi so it could talk to an ntp server and sort itself out.

View on HN

23510262 minutes from January 1st, 1970 is 2014 September 13, 01:42:00. Matches that date exactly.

Yes, they included that in their post below the picture.

    > NSDate dateWithTimeIntervalSince1970:23510262*60
    2014-09-13 13:42:00 +0000

Btw, are they using an Objective C repl?

That might be fscript?

http://www.fscript.org

Yes, it's F-Script. Playgrounds pre-Swift :)

I'm surprised the default time/date is UNIX epoch + 0. Realistically, it ought to be the date that version of iOS was released.

No programmer ever wished for more special cases when integrating date handling code, especially on a networked device and one that's so tightly integrated with other platforms and devices. And imagine the nightmare of testing the device pre-release, all while faking out the dates, both local and on NTP servers and on development desktop machines the under-development devices are tethered to, and somehow knowing exactly when the release day was going to be, possibly years in advance. So... no, I'm not sure about that plan. And I guess the bug would be unaffected in any case.

> And imagine the nightmare of testing the device pre-release, all while faking out the dates

Huh? Why would you set the date to one in the future? Make the date be the one of the build.

Why is that realistic?

Even if the implementation hurdles raised by others would be overcome, as I am certain they could be, this would help how?

Presumably because it would be impossible to set the time back to 1970, avoiding associated issues.

... but it wouldn't prevent setting time to 2014. Again, how does this help?

Reply on news.ycombinator.com