[Milhouse]

Maybe this is a new behaviour in recent kernels...

This had me scratching my head, but this is why the default date appears to match the build date.

Since systemd 229:

Code:

* On boot-up, when PID 1 detects that the system clock is behind the
  release date of the systemd version in use, the clock is now set
  to the latter. Previously, this was already done in timesyncd, in order
  to avoid running with clocks set to the various clock epochs such as
  1902, 1938 or 1970. With this change the logic is now done in PID 1
  in addition to timesyncd during early boot-up, so that it is enforced
  before the first process is spawned by systemd. Note that the logic
  in timesyncd remains, as it is more comprehensive and ensures
  clock monotonicity by maintaining a persistent timestamp file in
  /var. Since /var is generally not available in earliest boot or the
  initrd, this part of the logic remains in timesyncd, and is not done
  by PID 1.

Since build #0522, systemd is being rebuilt during each incremental build while PR:382 (bump to systemd 230) remains unmerged upstream. Consequently the release date of systemd closely approximates to the date/time of the build in which it appears, because systemd is being rebuilt on a daily basis.

Prior to build #0522, systemd was last built during a private (unreleased) clean build on May 20, when the systemd package was built at 12:40. If you were to boot the released build #0521 which did not need to rebuild systemd, you will see the default date is "May 20 12:40:32".

When PR:382 merges upstream, systemd will be built once more and then subsequent incremental builds will no longer rebuild systemd, at which point the default date will no longer match (or approximate to) the build date.