Hi Jim! At 2020-12-12T21:19:38-0800, Jim Avera wrote: > The registers \n[mo] \n[dy] etc. seem to not respect the current time > zone,
As far as I know, this is _not_ the case; groff sets its date/time registers based upon the local time when the troff process starts. You can inspect your local installation's behavior with a one-liner. $ groff .tm \n[year]-\n[mo]-\n[dy] \n[hours]:\n[minutes]:\n[seconds] [Control+D] For example, when I did this, I got "2020-12-14 10:33:16" (I'm in a fairly "advanced" time zone). > and so (for example) the \*(DT string provided by -mm shows the > wrong day for several hours each day. Now this part is interesting. A similar one liner reveals a surprising difference. $ groff -mm .tm \*[DT] ...I get "December 13, 2020". I ran the above _after_ the previous example, so something is definitely afoot here. > I suspect groff is always in UTC (but haven't confirmed). No, that is not true, at least not in groff as provided by GNU. A downstream distributor, like a GNU/Linux distribution, could alter this. > Is this a bug or intended? There have been suggestions to _make_ UTC the default, or at least to provide an option enabling it, to better facilitate reproducible build efforts. > How can I make mm's \*(DT show the correct date in my timezone? I know > I can manually override the automatic value using .ND and some kind of > wrapper script to auto-insert the macro call or something... but > that's not very attractive. It seems to me like mm's DT string is already doing this. When I get a chance I will examine the implemenation and follow up further. Regards, Branden
signature.asc
Description: PGP signature