Re: How to make groff use local timezone?

[G. Branden Robinson]

At 2020-12-14T14:12:28+1100, G. Branden Robinson wrote:
> > 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.
> 
> 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.

Mystery solved.  I slipped up and used the installed system groff, which
is from Debian, when testing the -mm flag, so I was getting the date in
UTC as Colin noted.

> > 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.

No, it's not, and I don't think it can be seriously recommended as a
general solution.

Likely a groff-UTC fix would involve a new command-line flag or
environment variable, with the latter more probable based on what I
perceive to be the traditions of groff development and the preferences
of its contributors.

An obvious possibility would be to support one or the other of:

        GROFF_USE_UTC
or
        GROFF_USE_LOCAL_TIME

...where if the variable is set (and not null?), GNU troff makes the
appropriate assumption when populating the date/time registers in
src/roff/troff/input.cpp:init_registers().

I'm not able to imagine a strong case for adding a parallel set of
for "_utc" registers as Steffen suggested; the generation of a document
is under user control, as is groff's environment.  Therefore I don't see
the slippery semantics of the existing date/time registers as being a
problem; they already vary by time zone anyway, and there is no
mechanism within GNU troff for querying the time zone.  Even if there
were, deriving UTC from it reliably would be a tedious exercise (so many
lovely boundary cases).

What do people think about a GROFF_USE_UTC environment variable that
causes troff to call gmtime() instead of localtime()?

Regards,
Branden

signature.asc
Description: PGP signature