tzset() returns void, so i don't think there's a good way to detect such issues without date(1) having to make its own assumptions about how/where tz data is stored.
On Thu, Sep 19, 2024 at 6:54 PM Philip Rowlands <coreut...@dimebar.com> wrote: > On Thu, 19 Sep 2024, at 16:32, Chris Elvidge wrote: > > > "New Zealand" isn't in the timezone list so date doesn't understand it. > > Sure, but date also doesn't treat it as invalid: > > $ TZ=America/New_Yorkk src/date > Thu 19 Sep 23:50:55 America 2024 > > $ TZ=America/New_Yorkk src/date --debug > src/date: output format: ‘%a %e %b %H:%M:%S %Z %Y’ > Thu 19 Sep 23:50:58 America 2024 > > $ TZ=America/New_Yorkk src/date --debug -d now > date: parsed relative part: today/this/now > date: input timezone: TZ="America/New_Yorkk" environment value > date: using current time as starting value: '23:51:10' > date: using current date as starting value: '(Y-M-D) 2024-09-19' > date: starting date/time: '(Y-M-D) 2024-09-19 23:51:10' > date: '(Y-M-D) 2024-09-19 23:51:10' = 1726789870 epoch-seconds > date: timezone: TZ="America/New_Yorkk" environment value > date: final: 1726789870.496873414 (epoch-seconds) > date: final: (Y-M-D) 2024-09-19 23:51:10 (UTC) > date: final: (Y-M-D) 2024-09-19 23:51:10 (UTC+00) > src/date: output format: ‘%a %e %b %H:%M:%S %Z %Y’ > Thu 19 Sep 23:51:10 America 2024 > > > There's no indication, even in debug mode, that there's a typo in the TZ > value. > > > Cheers, > Phil > >
