I use 'date -d' a lot when debugging our services. I have not used 'date -s' for years at least, because time is never set manually for anything even close to production. (I would have even claimed the date is set by giving no option. Not checking this now, can do when I have to set system time next time...).

This story just stresses the old rule: Never ever use root / sudo routinely for commands that don't need it because nothing can go wrong / you know what you are doing.

One could also read this as a cautionary tale in not running as root if you can help it: `date -s` will fail out with a nice error message if run as an unprivileged user. Of course, that won't save you if you were intentionally running as root (one could easily imagine a shell script running as root and needing to convert dates), but it makes it harder to unintentionally break things.

My solution to such "risks" is to put things into aliases or shell functions. Or, as a more general advice: know your scripting language(s). For example:

perl -e 'print scalar localtime 1700000000' returns the readable date and could be the start of a script to do even more with such timestsamps, e.g. converting log files passed on stdin.

I purposefully only ever use (or even bothered to learn) the long option: date --date=@1700000000.

Or my personal favourite; crontab -e versus crontab -r.

d -> s (or a typo) I can get behind but there's just no way you one would type 'clear' instead of 'show' and expect the command to behave in a similar way