just checking in here: the issue is resolved with an SMC reset. This doesn't address the cause, but, for those of you with Macs that are seeing the issue...

SMC and PRAM resets have not helped in our case.

SMC will often temporarily resolve it but within the next 4 or 5 restarts it will start up again.

We have three impacted machines (i.e., system clock being 20 years into the future), all of which are "15-inch Retina MacBook Pro with TouchID (Late 2016)" models, running macOS 10.12.4.

Disconnecting USB-C adapters before booting seems to help.

We saw this on a 15-inch Retina MacBook Pro with TouchID (Late 2016)

The Date was flipping between November 13, then December 19 2037 in the system.log, occasionally jumping to the current date.
It was set to autoset from Apple time servers.
Not imaged, just updated to 10.12.4
We saw this behavior when using a Belkin USBC to GB Ethernet.

After I read this discussion, mentioned above
https://discussions.apple.com/thread/7904723?start=15&tstart=0

I followed the suggestion to install the realTek driver for the Belkin chipset inside the adapter from http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false and the date problem immediately stopped on this device.

Weird. Hope this helps someone.

AppleCare advised us today:

The product engineering team has made some progress on this issue and a change to ntp is being developed to help address this behavior. We will let you know immediately once this change has been integrated and a beta is available for testing.

@chris.hansen Thanks for the update! I was having that exact issue with the Belkin USB-C to GB adapter and did notice the time fix once unplugged/disconnected. Oh third party products! Surprised Apple hasnt made their "Official" adapter.....

@dan.snelson Thank you for the update!

An update from AppleCare:

macOS 10.12.5 beta 4 is now available to eligible users. The build is 16F67a and it is available to members of the AppleSeed for IT (https://appleseed.apple.com) and Apple Developer seed (https://developer.apple.com/download/) programs. The beta 4 release is expected to address this issue described in this case where the date can randomly jump to twenty years in the future (2040).

Please install the 10.12.5 beta 4 release on a test client and let us know if this appears to have addressed the issue.

Results from a single quick-and-dirty test:

On a single test machine, a 13-inch Retina MacBook Pro with TouchID (Late 2016), running macOS 10.12.5, Build 16F67a, the issue appears to be resolved.

Great news, thanks @dan.snelson

assuming you all have seen this?? :

[https://www.jamf.com/jamf-nation/discussions/22727/critical-update-won-t-install-after-imaging](link URL)

I've run into a different problem with a MacBook Pro (Retina, 13-inch, Early 2015), since the update to 10.12.4 we've been experiencing total lock-up during random workloads, designing in Adobe Creative Cloud, copying text from a website, clicking between windows on desktop. Can't seem to pinpoint the conflict. Anyone else have heard of similar?

Attached activity monitor screenshot to look for any conflicts.

Thanks.

@chris.hansen You helped me! I tried installing that Realtek driver for the date/time issue, and it also fixed my not being able to netboot issue! I shared your post on that feed, in case it helped anyone else. Thanks a million.

FYI: the Tripp-Lite U444-06N-DGU-C adapter will also cause this

FYI: the Tripp-Lite U444-06N-DGU-C adapter will also cause this

@grepoli Which issue will it cause?

Beta still has not provided a fix. Tried updating to Beta and the same issue persist. Spoke with our TAM and let them know. The weird thing about this issue is that various workarounds work but none 100%.

A few MacBookPro13,3 were being dropped off to me because the techs could not reimage or get a clean OS installed on them. They were behaving oddly after updating to 10.12.4, so one of the things they tried was to reimage them.

Reseting the SMC, zapping the PRAM, or using different types of Ethernet adapters did not resolve future year issue. The one's I've worked on have the year set to Dec 2040 or Jan 2041.

I've been able to (temporarily) resolve by booting from a USB drive with the 10.12.4 installer, opening Terminal, and then using the Date command to reset the hardware clock. Once set properly, then it will successfully netboot, net image, and/or Internet Recovery, or install 10.12.4 from a external USB drive.

Has anyone noticed that it's computers that are upgraded from 10.12.x to 10.12.4 via software updates that are effected - something included in the update process creates the problem? I wonder if installing 10.12.4 on a clean device will avoid the issue from coming back.

Using the date command gets them going again, but might not be the long term solution.

@jhalvorson It also happens on a clean 10.12.4 installation.

@sstammbach Yep. Since my prior post, I've witnessed that as well. AppleCare Support has informed me this will be addressed with 10.12.5. They didn't comment if it was an issue specific to which type of network adapter as a trigger. I'll see if I can get repeated problems with certain adapters or not.

@jhalvorson We only had issues with the Belkin USB-C Adaptor so far. No Problems with Dell, LMP, etc.
Yes, 10.12.5 (beta 4 & beta 5) are working fine until now. Hope it stays that way with the final release of 10.12.5...

Limited testing, I can get the date to jump to 203x or 204x periodically when: rebooting with a White Belkin USB-C to Ethernet (F2CU040) and a White Kanex USB-C to Ethernet (KU3CGBT) connected to a wired network.

I have not seen the date jump happen when using a Thunderbolt 3 to 2 PLUS Apple TB2 to Ethernet adapter. Nor when using a Aluminum StarTech USB-C to Ethernet (US1GC30A).

I'm definitely seeing this on non late 2016 MBP's too. Opened a case with Apple and their suggestions aren't working on this specific machine. Turning FV off allows the Mac to boot, but as soon as it is re-enabled back to boot looping.

Fun.

We are having this issue too. Worst possible time as well since we've just begun the JAMF rollout to replace our current solution of Centrify.

In any case we've had about 3-4 users affected. We initially thought it was JAMF causing it, based on how we did the migration but have now seen it happen on out of box models. It appears that FV 10.12.4 Belkin USB C to Gigabit E are the wild cards. Problem is now our machines are stuck with FV enabled and unable to disable or run the following which JAMF provided us:

1. Boot into single user mode and run the below commands

mount -uw /
kextcache -u /
exit

1. This will boot the system into the OS where you can disable FileVault, fix the time, remove any attached dongles, then re-enable FileVault.

10.12.5 released. "...Resolves an issue, affecting some enterprise and education customers, that may cause the system date to be set to the year 2040...." among other things.

@chris.hansen fingers crossed running on one of my plagued machines! I was able to finally decrypt, but odd procedure. Ran the decryption first in Recovery Mode but it kept saying Paused. Booted into Target Disk Mode and then ran the command to check the status and sure enough it was chugging along. Thought it was sort of bizarre that the decryption was actively running in TDM. 3 hours later and I was back into the users' machine.

Running the 10.12.5 patch, re-encrypting and praying for the best.