If you haven’t read part 1 yet, make sure you start there.

This issue has really intrigued me.

Setting the date manually fails:

root@nems:/var/log# date
Mon Aug 28 06:39:22 EDT 2113
root@nems:/var/log# date -s "2018-07-05"
date: cannot set date: Invalid argument
Thu Jul  5 00:00:00 EDT 2018

Invalid argument? Maybe it wants me to set the time too?

root@nems:/var/log# date -s "2018-07-05 20:13:01"
date: cannot set date: Invalid argument
Thu Jul  5 20:13:01 EDT 2018

Nope, that made no difference.

Well, what does my hardware clock say (since the Pine A64+ has one)?

root@nems:/var/log# hwclock
2018-07-05 20:13:10.747892-0400

Oh yay, that looks better! Let’s use that! Obviously the system knows the date and time…

root@nems:/var/log# date -s "$(hwclock)"
date: cannot set date: Invalid argument
Thu Jul  5 20:14:20 EDT 2018

Oh, COME ON!

Maybe I’ll try the long-form command…

root@nems:/var/log# date --set="$(hwclock)"
date: cannot set date: Invalid argument
Thu Jul  5 20:15:49 EDT 2018

Nope. Same result. Ach!

This is looking a lot like an old kernel bug I recall from the late 2000’s. Better check what kernel I’m running…

root@nems:/var/log# uname -a
Linux nems 4.14.26 #1 SMP Sun Mar 11 16:34:42 UTC 2018 aarch64 GNU/Linux

If I had hair…

Just to be sure, let’s reconfigure my timezone config:

root@nems:/var/log# dpkg-reconfigure tzdata

Current default time zone: 'America/New_York'
Local time is now:      Mon Aug 28 06:47:54 EDT 2113.
Universal Time is now:  Mon Aug 28 10:47:54 UTC 2113.

root@nems:/var/log# hwclock
2018-07-05 20:19:51.275648-0400

Okay, so let me get this straight… it’s August 28, 2113. But it’s July 5, 2018 according to the RTC.

Think, Robbie, think.

I did a quick grep through the /var/log folder for anything talking about ntp, and interestingly, I find this at the top of dpkg.log:

2018-07-04 08:59:23 startup archives unpack
2018-07-04 08:59:24 install ntpstat:arm64 <none> 0.0.0.1-1+b1
2018-07-04 08:59:24 status half-installed ntpstat:arm64 0.0.0.1-1+b1
2018-07-04 08:59:24 status unpacked ntpstat:arm64 0.0.0.1-1+b1
2018-07-04 08:59:24 status unpacked ntpstat:arm64 0.0.0.1-1+b1
2018-07-04 08:59:24 startup packages configure
2018-07-04 08:59:24 configure ntpstat:arm64 0.0.0.1-1+b1 <none>
2018-07-04 08:59:24 status unpacked ntpstat:arm64 0.0.0.1-1+b1
2018-07-04 08:59:24 status half-configured ntpstat:arm64 0.0.0.1-1+b1
2018-07-04 08:59:24 status installed ntpstat:arm64 0.0.0.1-1+b1
2113-08-27 19:31:23 startup archives unpack
2113-08-27 19:31:23 install ntpdate:arm64 <none> 1:4.2.8p10+dfsg-3+deb9u2
2113-08-27 19:31:23 status half-installed ntpdate:arm64 1:4.2.8p10+dfsg-3+deb9u2
2113-08-27 19:31:24 status unpacked ntpdate:arm64 1:4.2.8p10+dfsg-3+deb9u2
2113-08-27 19:31:24 status unpacked ntpdate:arm64 1:4.2.8p10+dfsg-3+deb9u2
2113-08-27 19:31:24 startup packages configure

So on first boot, the system had the date correct: July 4, 2018. The time is off by a couple hours however (it was perhaps 6am when I flashed and fired up the system and then left for work).

What’s interesting here is that the typical ntp startup tasks unpack, install and run, but then after the package is installed (a presumably automated process since I didn’t do it!) the date suddenly changes to August 27, 2113.

Being a Raspberry Pi user all my SBC life, I’m honestly impressed that the Pine A64+ has a built-in RTC… but nowhere in the specs do I see that it also includes a corresponding flux capacitor, so I must presume the jump through time is more likely a glitch in the matrix.

I’m afraid to reboot.

What’s Next? Read Part 3:

NTP on Debian reporting 95 years in the future – Part 3: Community