The registers \n[mo] \n[dy] etc. seem to not respect the current time
zone, and so (for example) the \*(DT string provided by -mm shows the
wrong day for several hours each day.
I suspect groff is always in UTC (but haven't confirmed). Is this a
bug or intended?
How can I make mm's \*(DT s
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 i
On Mon, Dec 14, 2020 at 02:12:28PM +1100, G. Branden Robinson wrote:
> At 2020-12-12T21:19:38-0800, Jim Avera wrote:
> > 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 dis
On Mon, 14 Dec 2020, Colin Watson wrote:
On Mon, Dec 14, 2020 at 02:12:28PM +1100, G. Branden Robinson wrote:
At 2020-12-12T21:19:38-0800, Jim Avera wrote:
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
downstrea
Colin Watson wrote in
<20201214154336.ga32...@riva.ucam.org>:
|On Mon, Dec 14, 2020 at 02:12:28PM +1100, G. Branden Robinson wrote:
|> At 2020-12-12T21:19:38-0800, Jim Avera wrote:
|>> I suspect groff is always in UTC (but haven't confirmed).
|>
|> No, that is not true, at least not in gro
At 2020-12-12T21:19:38-0800, Jim Avera wrote:
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.
Hmm. In Ubuntu 20.04 `groff --version` says "ver
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 ge
On 12/15/20 4:21 PM, Jim Avera wrote:
In Ubuntu 20.04 `groff --version` says "version 1.22.4", but seems to
ignore TZ...
I downloaded the source for 1.22.4 and built it, and TZ works as expected.
So Ubuntu (or Debian) must have somehow screwed with it. I'll submit
an Ubuntu bug report.
S
On Wed, Dec 16, 2020 at 11:35:12AM +1100, G. Branden Robinson wrote:
> What do people think about a GROFF_USE_UTC environment variable that
> causes troff to call gmtime() instead of localtime()?
How would this differ from just setting TZ=UTC?
Also, this conversation seems to overlap substantiall
At 2020-12-16T10:54:40+, Colin Watson wrote:
> On Wed, Dec 16, 2020 at 11:35:12AM +1100, G. Branden Robinson wrote:
> > What do people think about a GROFF_USE_UTC environment variable that
> > causes troff to call gmtime() instead of localtime()?
>
> How would this differ from just setting TZ=
On 12/20/20, G. Branden Robinson wrote:
> Thoughts from anyone reading?
I concur with all points of this plan.
On Sunday, 20 December 2020 06:10:25 GMT G. Branden Robinson wrote:
> 2. Switch output of date comments embedded by output drivers off by
> default, and add a common option to reënable them. Document this in
> NEWS.
> 3a. Add a device-independent output command, something like "x
> ti
On 12/21/20, Deri wrote:
> Consider the case where multiple -Z produced groff files,
> produced at different times, are combined into one gropdf run. The only
> sensible time to include
> in the meta-data is the time the pdf was created, why lose potentially
> useful information?
If you need to k
On Tuesday, 22 December 2020 00:24:15 GMT Dave Kemper wrote:
> Are there cases where the timestamp within the file would differ from
> the timestamp *of* the file? This typically happens when a file is
> edited after it's created -- which could be common with HTML output,
> but would seem to be ra
At 2020-12-21T23:33:18+, Deri wrote:
> On Sunday, 20 December 2020 06:10:25 GMT G. Branden Robinson wrote:
> > 2. Switch output of date comments embedded by output drivers off by
> > default, and add a common option to reënable them. Document this in
> > NEWS.
> > 3a. Add a device-ind
Hello fellow groffers,
As a consumer , archiver of pdf documents, image files and others. I'm
confronted with all that goes wrong when trying to keep systemdates of file
synced and keep the same as the original creation date. I've had so many
issues with systemdates that or wrongly set , or a webd
On Tuesday, 22 December 2020 03:41:14 GMT G. Branden Robinson wrote:
> > I may be misunderstanding something here, apologies if I am.
>
> No, I appreciate you speaking up--I welcome critical evaluation of my
> suggestions, especially in cases like this where I haven't carved out
> enough time to e
On Tue, Dec 22, 2020 at 01:29:44PM +, Deri wrote:
> Please can someone explain why reproducible builds are important.
Hi,
It's probably best to simply refer you to
https://reproducible-builds.org/ for general motivation, and then you
can come back with any questions you have.
> What is the o
I've made groff's build as reproducible as I can get it, as noted in the
comments to Savannah #57218[1]. The fix to pdfroff turned out to be
gentle and simple--just stop telling it to preserve temporary files
during the groff build. That neatly reduced the size of a build diff by
99%. What remai
On Tue, Dec 29, 2020 at 03:15:35PM +1100, G. Branden Robinson wrote:
> This issue is still open and tagged as a blocker for release, however.
> To resolve it we should settle on the time zone semantics of the system
> time retrieved by groff components (the formatter, the output drivers).
> We shou
On Sun, Jul 09, 2023 at 02:42:55AM +0100, Colin Watson wrote:
> So, how about the attached patch?
I somehow neglected to update doc/groff.texi. Here's an updated
version.
--
Colin Watson (he/him) [cjwat...@debian.org]
>From 522c4beb20414e8ceb6b321bbc96df6f35a81a10 M
[adding Deri to CC]
At 2023-07-09T13:24:27+0100, Colin Watson wrote:
> On Sun, Jul 09, 2023 at 02:42:55AM +0100, Colin Watson wrote:
> > So, how about the attached patch?
>
> I somehow neglected to update doc/groff.texi. Here's an updated
> version.
I have no objection to this patch. I think C
On Sunday, 9 July 2023 17:59:04 BST G. Branden Robinson wrote:
> [adding Deri to CC]
>
> At 2023-07-09T13:24:27+0100, Colin Watson wrote:
> > On Sun, Jul 09, 2023 at 02:42:55AM +0100, Colin Watson wrote:
> > > So, how about the attached patch?
> >
> > I somehow neglected to update doc/groff.texi.
On Sun, Jul 09, 2023 at 11:59:04AM -0500, G. Branden Robinson wrote:
> At 2023-07-09T13:24:27+0100, Colin Watson wrote:
> > On Sun, Jul 09, 2023 at 02:42:55AM +0100, Colin Watson wrote:
> > > So, how about the attached patch?
> >
> > I somehow neglected to update doc/groff.texi. Here's an updated
On Sun, Jul 09, 2023 at 07:13:54PM +0100, Deri wrote:
> It looks Ok, not tested. I'm happy for you to apply.
Thanks.
> Once gropdf moves to the font subsetting version it will cause a
> problem for reproducible builds, since the gubbins inside the pdf
> changes enormously, but it should look iden
On Sunday, 9 July 2023 19:26:36 BST Colin Watson wrote:
> On Sun, Jul 09, 2023 at 07:13:54PM +0100, Deri wrote:
> > It looks Ok, not tested. I'm happy for you to apply.
>
> Thanks.
>
> > Once gropdf moves to the font subsetting version it will cause a
> > problem for reproducible builds, since th
On Sun, Jul 09, 2023 at 07:13:54PM +0100, Deri wrote:
> On Sunday, 9 July 2023 17:59:04 BST G. Branden Robinson wrote:
> > I have no objection to this patch. I think Colin is right that none
> > but reproducible-build mavens are going to use $SOURCE_DATE_EPOCH.
[...]
> It looks Ok, not tested. I'm
27 matches
Mail list logo
