[apaprocki]

Really disappointed that the author did not want to delve into TZ dark magic:

  $ date && TZ=LOLS-3:03:03LOLD,J101,J202 date
  Wed Feb 10 17:44:44 EST 2021
  Thu Feb 11 01:47:47 LOLS 2021

(My timezone is LOL Standard Time (LOLS), UTC+03:03:03, with support for changing to LOL Daylight Time (LOLD) during daylight savings, entering LOLD on the 101st Julian day of the calendar, and leaving on the 202nd Julian day of the calendar, excluding February 29th even in leap years.)

[dan-robertson]

I find this magic quite unpleasant. It causes a massive amount of confusion (eg if you write TZ=UTC+8, you actually get UTC-8, except it’s called UTC. You’d actually need to type eg TZ=XYZ-8 because you subtract 8 hours to get UTC. The theory at the time was that it made it easier to enter US timezones like UTC-5.) Furthermore, some applications won’t parse a timezone that isn’t in the local tzdb so you’d actually need to enter eg TZ=Etc/GMT-8 for UTC+8. And heaven forfend an application might parse TZ=UTC+8 in the “normal” way instead of the posix way. What a recipe for disaster. Encoding daylight savings in the env var just makes the whole mess worse.