summaryrefslogtreecommitdiff
path: root/pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch
diff options
context:
space:
mode:
authorAndreas Rammhold <andreas@rammhold.de>2021-12-31 14:12:56 +0100
committerFlorian Klink <flokli@flokli.de>2022-03-05 21:27:45 +0100
commitd67caf3c894ed5424ba73b6d39db2eddf25bc128 (patch)
tree005a23606569a5e719b6459d7fe9e8ff19a1e8b7 /pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch
parente6280a639759ff6343a9d63e83c0466f17281a68 (diff)
nixos/timesyncd: initialize clock file with current time
When initializing a system (e.g. first boot / livecd) we have no good reference source for time. systemd-timesyncd however would revert back to its configured fallback time (in our case 01.01.1980). Since we probably don't want to hardcode a specific date as fallback we are now using the current system time (wherever that might have come from) to initialize the reference clock file. The only systems that might be remotely affected by this change are machines that have highly unreliable RTCs or those where the battery that backs the RTC is running empty. Historically these systems always had a tough time with anything time related and likely required manual intervention. For stateless systems (those that wipe / between reboots or our installer CDs) this has the consequence that time will always be reset to whatever the system comes up with on boot. This is likely the correct time coming from an RTC. No harm done here the situation is likely unchanged for them. For stateful systems (those that retain the / partition across reboots) there shouldn't be a change at all. They'll provide an initial clock value once on their lifetime (during first boot / after installation). From then onwards systemd-timesyncd will update the file with the newer fallback time (that will be picked up on the next boot).
Diffstat (limited to 'pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch')
0 files changed, 0 insertions, 0 deletions