First off, what a weird example you found. But more on the matter. Is your change even good advice? pool.ntp.org is attackable via unauthenticated DNS, and based upon past experience who can say if their administrators can even keep their infrastructure secure. Furthermore, the ntp protocol has no security and can be man-in-the-middled to provide lies (in a ntp daemon one can listen to many replies and get some confidence, but this rdate example is one-shot).
So at best this gives you a potentially correct answer about Germany, not considering the leap second, and not considering TZ database changes which seem to be happening continually and "Legally". So an alternative proposal: Should this weird EXAMPLES section be deleted? Ted Unangst <[email protected]> wrote: > The sample server doesn't work for me, and while the example is a fun hint at > the alternate universe of "right" and "legal" times, I don't think this is a > good place to suggest actually changing the system timezone. > > Demonstrate printing a time modified by TZ instead. > > > Index: rdate.8 > =================================================================== > RCS file: /cvs/src/usr.sbin/rdate/rdate.8,v > retrieving revision 1.37 > diff -u -p -r1.37 rdate.8 > --- rdate.8 10 Feb 2015 13:10:27 -0000 1.37 > +++ rdate.8 6 Jan 2019 03:18:48 -0000 > @@ -93,18 +93,9 @@ Always show the adjustment. > record of date resets and time changes > .El > .Sh EXAMPLES > -To get the legal time in Germany, set the > -.Pa /etc/localtime > -symlink to > -.Pa /usr/share/zoneinfo/right/Europe/Berlin > -and issue the following command: > +To print the legal time in Germany, issue the following command: > .Pp > -.D1 Li "# rdate -v ptbtime1.ptb.de" > -.Pp > -The command of course assumes you have a working internet connection > -and DNS set up to connect to the server at > -.Sy Physikalisch-Technische Bundesanstalt > -in Braunschweig, Germany. > +.D1 Li "$ env TZ=right/Europe/Berlin rdate -p pool.ntp.org" > .Sh SEE ALSO > .Xr date 1 , > .Xr adjtime 2 , >
