GNU bug report logs - #36870
date bug

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36870 in the body.
You can then email your comments to 36870 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: bug-guix <at> gnu.org
Subject: date bug
Date: Wed, 31 Jul 2019 06:20:47 +0000

Hi Ludovic,

Please excuse my direct mail and speculative shot at CC-ing bug-guix ;-/
(Hope to get my email stuff in order RSN :)

Bug: The plain old date command seems confused about zone info,
as you can see from the following:

Bottom line: I would look for a regex that erroneously excludes
embedded forward slashes in forming the TZ key used to look up
the localtime date info in tables like

/gnu/store/xml1s9r9vp98amhyyn3q85p5xls3nivf-tzdata-2019a/share/zoneinfo/tzdata.zi

The date bug ripples into lots of dependents, such as "who -b" that first made me notice,
and lots more -- really need to fix! ;-)

$ 
$ echo $TZ # my current zone
America/Los_Angeles
$ # plain America without following slash does not exist in the table, so how does date punt then? Insert key itself as %Z?
$ egrep -m3 '^Z America([^/]|$)' /gnu/store/xml1s9r9vp98amhyyn3q85p5xls3nivf-tzdata-2019a/share/zoneinfo/tzdata.zi
$ egrep -m3 '^Z America([^/]|$)' /gnu/store/xml1s9r9vp98amhyyn3q85p5xls3nivf-tzdata-2019a/share/zoneinfo/tzdata.zi
$ egrep -m3 '^Z America([/]|$)' /gnu/store/xml1s9r9vp98amhyyn3q85p5xls3nivf-tzdata-2019a/share/zoneinfo/tzdata.zi
Z America/Danmarkshavn -1:14:40 - LMT 1916 Jul 28
Z America/Scoresbysund -1:27:52 - LMT 1916 Jul 28
Z America/Godthab -3:26:56 - LMT 1916 Jul 28
$ egrep -m3 '^Z America/Los' /gnu/store/xml1s9r9vp98amhyyn3q85p5xls3nivf-tzdata-2019a/share/zoneinfo/tzdata.zi
Z America/Los_Angeles -7:52:58 - LMT 1883 N 18 12:7:2
$ 

Earlier experiments, to get to above speculation, taken from emacs M-x shell:

(Many examples below contrast the /usr/bin/ versions from arch linux
with those redirected by guix profile links (more details follow))

-------------------------------------------------------------
[19:13 ~/bs]$ PS1='$ ' # minimize prompt overhead
$ 
$ # first noticed in wrong directory name I generate
$ # based on who -b -- which in turn depends on date
$ # which has the bug (produces UTC, but more to it):
$ date -Is
2019-07-31T02:22:29+00:00
$ /usr/bin/date -Is
2019-07-30T19:22:48-07:00
$ date --version
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
$ /usr/bin/date --version
date (GNU coreutils) 8.31
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
$ # but the real clue is from plain date, which mangles output order and TZ info:
$ date
Wed Jul 31 02:24:30 America 2019
$ /usr/bin/date
Tue 30 Jul 2019 07:24:45 PM PDT
$ which -a env
/home/bokr/.guix-profile/bin/env
/usr/bin/env
$ env|grep TZ
TZ=America/Los_Angeles
$ /usr/bin/env|grep TZ
TZ=America/Los_Angeles
$ uname -a
Linux PhantoNv4ArchGx 5.1.15-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 25 04:49:39 UTC 2019 x86_64 GNU/Linux
$ uname -rv
5.1.15-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 25 04:49:39 UTC 2019
$ grep -m1 'model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
$ ## BTW, for me, arch linux with kernel 5.2.x went glacial with unk busyness
$ ## and forced me to stay for now with 5.1.15 as "foreign distro" for my guix, which is
$ guix --version
guix (GNU Guix) 34e549d813113fc57213202fd5e4b885d95d0913
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ guix describe
Generation 6	Jul 11 2019 08:41:53	(current)
  guix 34e549d
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 34e549d813113fc57213202fd5e4b885d95d0913
$ 
$ ## I should probably do a pull and see if this has been fixed already, so, will do that...
$
2019-07-30 19:51:35 [ ] going for pull..

-------------------------------------------------------------

Well, that didn't fix it, unless reboot is required ...

$ guix describe
Generation 7	Jul 31 2019 03:25:55	(current)
  guix 274ba54
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 274ba54e535b811acca02e42cffd45f0f625d142
$ date
Wed Jul 31 03:44:28 America 2019
$ /usr/bin/date
Tue 30 Jul 2019 08:44:42 PM PDT
$ date  '+%F %T %z %Z'
2019-07-31 03:45:44 +0000 America
$ /usr/bin/date  '+%F %T %z %Z'
2019-07-30 20:46:12 -0700 PDT
$ file /etc/localtime 
/etc/localtime: symbolic link to /usr/share/zoneinfo/Europe/Stockholm
$ # but TZ env variable usually overrides (seemingly, in my setup), and I am
$ # currently in Seattle zone, and I change TZ in ~/.bash_profile to current
$ env|grep TZ
TZ=America/Los_Angeles
$ /usr/bin/env|grep TZ
TZ=America/Los_Angeles
$ date --version 
$ date --version
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
$ /usr/bin/date --version
date (GNU coreutils) 8.31
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
$
---------------------------------------
Hard to believe the 8.30 to 8.31 version difference accounts for the problem.

HTH,
Regards,
Bengt Richter

Message #8 received at 36870 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: 36870 <at> debbugs.gnu.org
Subject: bug#36870: was: date bug -- really locale bug or ??
Date: Tue, 6 Aug 2019 02:38:02 +0000

Hi all, following up on myself, sorry I lost my copy of
my original, so this does not contain any quoting, but
this can stand on its own as a new problem statement.

Problem should go away if I can get locales working,
but despite trying what purportedly has worked for others,
no luck. I hope it will be obvious to someone from the below ;-)

$ # first some context:
$ uname -rv
5.1.15-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 25 04:49:39 UTC 2019
$ guix -V
guile: warning: failed to install locale
guix (GNU Guix) a17fe3f01ac160a576135b03d23bc098ebf6fb31
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ ### that warning -- "guile: warning: failed to install locale" might be a clue in that
$ ### it does _NOT_ happen in the direct bash console environment, but does in emacs's M-x shell ...
$ cat ~/bin/pidparents  ## something to show where I am, that I find useful
#!/usr/bin/bash
# ~/bin/parentage

pid=${1:-$$}	#this process if no pid specified as $1

while [ $(($pid)) -gt 0 ]; do    
      ps h -p $pid -o comm,tt,pid,stat,args
      pid=$(ps -q $pid -o ppid=)
done
$ pidparents ## from here in emacs's shell
pidparents      pts/0     9286 S+   /usr/bin/bash /home/bokr/bin/pidparents
bash            pts/0     6884 Ss   /bin/bash --noediting -i
.emacs-26.2-rea tty4      6393 Sl+  /gnu/store/9nrncjaxygfrr9q749pymcw3l9vywh0k-emacs-26.2/bin/emacs-26.2 /home/bokr/.mutt/temp/mutt-PhantoNv4ArchGx-1000-6327-
mutt            tty4      6327 S    mutt
bash            tty4     24159 S    bash
bash            tty4      3608 Ss   -bash
login           ?         3601 Ss   login -- bokr
systemd         ?            1 Ss   /sbin/init \EFI\PhantoNv4ArchGx\vmlinuz-linux
$ ### does something depend on ttyN vs pts/N ?? don't think so, but maybe some env gets lost in pts start?
$
$ 
$ ### here I call the guix date vs the archlinux date at /usr/bin/date -- note the difference
$ which -a date
/home/bokr/.guix-profile/bin/date
/usr/bin/date
$ 

$ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n    :g'
openat(AT_FDCWD,
     "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
     O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(1<pipe:[319076]>,
     "Mon Aug  5 18:22:52 America 2019"...,
     33Mon Aug  5 18:22:52 America 2019
$ 
$ strace -y /usr/bin/date|& egrep 'America|^write'|sed -e 's:,:,\n    :g'
openat(AT_FDCWD,
     "/usr/share/zoneinfo/America/Los_Angeles",
     O_RDONLY|O_CLOEXEC) = 4</usr/share/zoneinfo/America/Los_Angeles>
fstat(4</usr/share/zoneinfo/America/Los_Angeles>,
     {st_mode=S_IFREG|0644,
     st_size=2836,
     ...}) = 0
fstat(4</usr/share/zoneinfo/America/Los_Angeles>,
     {st_mode=S_IFREG|0644,
     st_size=2836,
     ...}) = 0
read(4</usr/share/zoneinfo/America/Los_Angeles>,
     "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
     4096) = 2836
lseek(4</usr/share/zoneinfo/America/Los_Angeles>,
     -1802,
     SEEK_CUR) = 1034
read(4</usr/share/zoneinfo/America/Los_Angeles>,
     "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
     4096) = 1802
close(4</usr/share/zoneinfo/America/Los_Angeles>) = 0
write(1<pipe:[320852]>,
     "Mon 05 Aug 2019 11:23:06 AM PDT\n",
     32Mon 05 Aug 2019 11:23:06 AM PDT
$
;;;;;;;;;;;;;;;;

I put

export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale/"
export LC_ALL=en_US.utf8

in both ~/.bash_profile and ~/.bashrc
and still no joy
 
I'm wondering whether I have to reboot, not just log out and back in,
to get locales into effect. Have been trying and searching, but something
is eluding me ;-/ [later, after rebooting -- nope, reboot didn't do it :( ]

Generation 37	Aug 02 2019 01:42:29
 + tzdata	2019b	out	/gnu/store/kmsqjsrwryfnz6p9pb4yysly71221blv-tzdata-2019b

Generation 38	Aug 04 2019 15:39:34
 + glibc-locales	2.28	out	/gnu/store/bb9alx1ap57pz0vmx7p1r8qk0lxxfg3x-glibc-locales-2.28

Generation 39	Aug 05 2019 08:08:19
 + localed	241	out	/gnu/store/98mpw3n6j34dsnq63hb14bpfv9bxq9f4-localed-241

(Hm, guess I ought to clean out some generations)

Any ideas appreciated. Am I the only one seeing this?
I first noticed because who -b gave me UTC time instead of local time.

Thanks.
Regards,
Bengt Richter

Message #11 received at 36870 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Bengt Richter <bokr <at> bokr.com>
Cc: 36870 <at> debbugs.gnu.org
Subject: Re: bug#36870: was: date bug -- really locale bug or ??
Date: Tue, 06 Aug 2019 02:54:03 -0400

Hi Bengt,

I'm sorry that I didn't have time to fully read your messages, but if I
understand correctly from my quick skimming, the 'date' command from
Guix is failing to access the zoneinfo.  I think I see your problem.

Bengt Richter <bokr <at> bokr.com> writes:
> $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n    :g'
> openat(AT_FDCWD,
>      "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
>      O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

The file name above suggests that your TZDIR variable is not set
correctly to allow Guix-built binaries to find the zoneinfo files.

On Guix systems, /etc/environment includes an entry that sets TZDIR to
the equivalent of "$(guix build tzdata)/share/zoneinfo".

When using Guix on top of another distro, an alternative choice might be
to set TZDIR to "/usr/share/zoneinfo".  I'm not sure which setting is
preferable on non-Guix systems.

Can you try setting TZDIR and see if that solves the problem for you?

     Regards,
       Mark

Message #14 received at 36870 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 36870 <at> debbugs.gnu.org
Subject: Re: bug#36870: was: date bug -> locale inconvenience -> suggestion :)
Date: Tue, 6 Aug 2019 16:31:48 +0000

On +2019-08-06 02:54:03 -0400, Mark H Weaver wrote:
> Hi Bengt,
> 
> I'm sorry that I didn't have time to fully read your messages, but if I
> understand correctly from my quick skimming, the 'date' command from
> Guix is failing to access the zoneinfo.  I think I see your problem.
> 
> Bengt Richter <bokr <at> bokr.com> writes:
> > $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n    :g'
> > openat(AT_FDCWD,
> >      "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
> >      O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 
> The file name above suggests that your TZDIR variable is not set
> correctly to allow Guix-built binaries to find the zoneinfo files.
> 
> On Guix systems, /etc/environment includes an entry that sets TZDIR to
> the equivalent of "$(guix build tzdata)/share/zoneinfo".
> 
> When using Guix on top of another distro, an alternative choice might be
> to set TZDIR to "/usr/share/zoneinfo".  I'm not sure which setting is
> preferable on non-Guix systems.
> 
> Can you try setting TZDIR and see if that solves the problem for you?
> 
>      Regards,
>        Mark

Thanks, that works using either /usr/... or /gnu/...

but I am thinking everything guix should be accessed via
some profile if it's configurable?

There is already a suggestion to source like this:

GUIX_PROFILE="$HOME/.guix-profile"
. "$GUIX_PROFILE/etc/profile"

I think it would be nice if that were the only ~/.bash_profile
mod a foreign-system user would have to make to tie into the
guix packages such user installs with guix install.

So what about having that GUIX_PROFILE profile -- at its end --
source ~/.guixrc if it exists, and then when some installation wants
to suggest some environment settings, just automatically
append commented-out code to ~/.guixrc.

Then the friendly hints at then end of an install could suggest:

    ┌──────────────────────────────────────────────┐
    │ "Consider uncommenting some of the new       │
    │ lines we just added at the end of ~/.guixrc" │
    └──────────────────────────────────────────────┘

(sorry if utf8 box-drawing characters are a nono here -- are they? ;-/ )

I had noticed the TZDIR name looking with "guix edit tzdata",
and was trying to figure out why installing had not hinted
that I might need to do what you suggest above :)

Thanks again.

Regards,
Bengt Richter

Message #19 received at 36870-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Bengt Richter <bokr <at> bokr.com>
Cc: Mark H Weaver <mhw <at> netris.org>, 36870-done <at> debbugs.gnu.org
Subject: Re: bug#36870:
Date: Mon, 26 Aug 2019 12:11:56 +0200

Hi,

Bengt Richter <bokr <at> bokr.com> skribis:

> On +2019-08-06 02:54:03 -0400, Mark H Weaver wrote:
>> Hi Bengt,
>> 
>> I'm sorry that I didn't have time to fully read your messages, but if I
>> understand correctly from my quick skimming, the 'date' command from
>> Guix is failing to access the zoneinfo.  I think I see your problem.
>> 
>> Bengt Richter <bokr <at> bokr.com> writes:
>> > $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n    :g'
>> > openat(AT_FDCWD,
>> >      "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
>> >      O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>> 
>> The file name above suggests that your TZDIR variable is not set
>> correctly to allow Guix-built binaries to find the zoneinfo files.
>> 
>> On Guix systems, /etc/environment includes an entry that sets TZDIR to
>> the equivalent of "$(guix build tzdata)/share/zoneinfo".
>> 
>> When using Guix on top of another distro, an alternative choice might be
>> to set TZDIR to "/usr/share/zoneinfo".  I'm not sure which setting is
>> preferable on non-Guix systems.
>> 
>> Can you try setting TZDIR and see if that solves the problem for you?
>> 
>>      Regards,
>>        Mark
>
> Thanks, that works using either /usr/... or /gnu/...

Good, closing!

> but I am thinking everything guix should be accessed via
> some profile if it's configurable?
>
> There is already a suggestion to source like this:
>
> GUIX_PROFILE="$HOME/.guix-profile"
> . "$GUIX_PROFILE/etc/profile"
>
> I think it would be nice if that were the only ~/.bash_profile
> mod a foreign-system user would have to make to tie into the
> guix packages such user installs with guix install.
>
> So what about having that GUIX_PROFILE profile -- at its end --
> source ~/.guixrc if it exists, and then when some installation wants
> to suggest some environment settings, just automatically
> append commented-out code to ~/.guixrc.

I agree that it’d be nice to somehow tell users about ‘TZDIR’, but I’m
reluctant to introducing yet another profile file.

I’m not sure what would be the best approach!

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.