I am the author of the original patch, and I have to say it is very neat seeing the attention it is getting.
I am really enjoying the discussion about how to make the patch better, but note that the original patch was deliberately kept extremely, almost offensivly, simple. like one early comment found I even tried to avoid an extra variable, because it is already a variable, an environment variable. While I think the modifications make the patch better and should be kept, I wanted to provide some context and justification for my original choices. > The recent change to grdc(6), to display additional information if TZ is > set, has a few issues. > > 1. Time zone offset incorrectly reported in Newfoundland. > > Some time zones have offsets of 30 or 45 minutes. The displayed time > offset is currently truncated to the closest hour. (Australia/Eucla > is a fun time zone too.) After a bit of soul searching I decided to abandon those souls in a non hour aligned TZ this is partialy because it is still mostly correct and I did not want to waste the space. But mainly because the numerical offset was only there for a secret underhanded reason. > > 2. The new, additional information disappears if the window is sized too > small (wintoosmall). There's basically room for it though... except I felt this was a feature, for free even. > 3. The TZ information is a string of unknown length, and so it doesn't > necessarily display correctly. > > Yeah, I know with pledge() you can't do testing like > TZ=:/home/pjanzen/dev/usr/share/zoneinfo/testing/2022/America/Kentucky/Monticello > any more, even though that's a perfectly cromulent and functional TZ on my > system otherwise. So for the time being, probably any TZ that exists and > doesn't abort grdc is 38 bytes or shorter. Which works. > > But, if your timezone exists, it already has its name in short form > included in tm->tm_zone. That's what I think should be > printed, even if "EDT" is way less cool than "America/Pangnirtung". I > mean, if the point is just to be able to label clocks with nice places, > instead of the time zone it's showing, maybe it could be a different option. > > Counterpoint: some of the timezones have short names that are just the UTC > offset, which is really boring and duplicated given that we print out the > offset already. Hey, maybe we could just print the offset... > > 4. There's no indication if you type an invalid TZ--you get UTC and a > misleading label onscreen. > > Timezone handling defaults to UTC if anything breaks along the chain, as > the tzset(3) man page makes clear. That means if you misspell Antarctica > while setting your TZ=Antartica/McMurdo, you'll end up half a day off from > all your pals at McMurdo as your screen happily tells you that you're > seeing McMurdo +0 time. > > There's no simple way to tell if your $TZ is valid or not (if you get back > UTC, maybe that's really what it should be!). At least if we display > tm->tm_zone rather than $TZ, we're not misleading. I had this exact problem, I looked into what it would take to validate that a TZ was correct and decided that loading the entire tz ecosystem just to to figure this out was far too much complication for grdc to take. So the solution was simple. Show the hour offset numericly, If this was different from the expected offset, you knew your TZ was wrong. And thus the neferious reason why the the numerical hour exists. I then decided I really liked seeing the offset numericly so double win. > > > I was going to be upset that the man page for grdc(6) is way pickier on TZ > than tzset(3), but it's quite accurate given the pledge() call. Speaking > of which, I don't expect any one else plays with timezone files, and surely > one doesn't want one's general utilities to be pwned by possible bugs in > the time-handling code exploited with custom files created outside > /usr/share/zoneinfo. But it's still a touch irritating-should-be-fixable > that, because the pledge() has to be after initscr(), grdc has the > possibility of leaving the terminal in the wrong state when it aborts on > test TZ files. > > > > Paul Janzen. > Cheers, Thank you very much for sharing your interest in the subject.
