On Wed, Oct 23, 2019 at 10:40:00PM +0300, Niko Tyni wrote:
> Control: found -1 5.30.0-8
>
> On Fri, Jul 03, 2015 at 11:16:46PM +0300, Niko Tyni wrote:
> > On Mon, May 04, 2015 at 02:28:04PM +0200, Jérémy Bobbio wrote:
>
> > > Another issue that surfaced now that we are doing timezone variations is
> > > that LOCALTIME_MIN and LOCALTIME_MAX gets different values depending on
> > > the value of the TZ environment variable.
> >
> > > The minimum I had on my amd64 system is with TZ=UTC-24, -62167305600.
> > > The maximum is with TZ=UTC and is 67768036191590399.
> > >
> > > It feels like a bug to have something that can be configured through an
> > > environment variable on a running system affect what gets encoded in the
> > > binary.
> >
> > This feels like a bug to me too, and should be handled separately.
> > I'm cloning this and will export TZ=UTC in debian/rules, at least
> > for now.
>
> The TZ=UTC part was accidentally dropped in the build system debhelper
> conversion for 5.30 packaging. This resulted in a reproducibility
> regression that Holger pointed out to me on IRC (thanks!).
>
> I'll re-instate TZ=UTC in 5.30.0-9 or so, but clearly the underlying
> issue remains.
Hi Niko,
I'm struggling to see the practical problem with having the timezone
vary LOCALTIME_{MIN,MAX} (other than reproducibility, which AIUI has
already been addressed). I don't agree with the starting point that
an environment variable shouldn't be able to influence the contents
of the binary (this is clearly a very common and necessary pattern).
Could you elaborate on your reasoning for keeping this bug open?
Thanks
Dominic
