GNU bug report logs -
#40958
date command give current time zone regardless of seconds since epoch requested.
Previous Next
Reported by: GNAT <gnat <at> 1.gnat.bgcomp.co.uk>
Date: Wed, 29 Apr 2020 10:26:01 UTC
Severity: normal
Tags: notabug
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
Message #18 received at control <at> debbugs.gnu.org (full text, mbox):
tag 40958 + notabug
close 40958
thanks
GNAT via GNU coreutils Bug Reports wrote:
> I am going to hazard a guess and say this is the expected behaviour,
> but I cannot find anything though goog.
The FAQ gives the recipe to figure these types of problems out.
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
And for the timezone and date in question.
zdump -v Europe/London | grep 1970
...no output...
That would be a little confusing. So let's look at it with a pager
such as less. Browse and find the years of interest.
zdump -v Europe/London | less
...
Europe/London Sun Feb 18 01:59:59 1968 UT = Sun Feb 18 01:59:59 1968 GMT isdst=0 gmtoff=0
Europe/London Sun Feb 18 02:00:00 1968 UT = Sun Feb 18 03:00:00 1968 BST isdst=1 gmtoff=3600
Europe/London Sat Oct 26 22:59:59 1968 UT = Sat Oct 26 23:59:59 1968 BST isdst=1 gmtoff=3600
Europe/London Sat Oct 26 23:00:00 1968 UT = Sun Oct 27 00:00:00 1968 BST isdst=0 gmtoff=3600
Europe/London Sun Oct 31 01:59:59 1971 UT = Sun Oct 31 02:59:59 1971 BST isdst=0 gmtoff=3600
Europe/London Sun Oct 31 02:00:00 1971 UT = Sun Oct 31 02:00:00 1971 GMT isdst=0 gmtoff=0
...
And therefore it is of course as Andreas Schwab wrote. "This took
place between 27 October 1968 and 31 October 1971, ..." An
interesting footnote of history!
The date command uses the Time Zone Database for this information.
The database is typically updated by the operating system software
distribution upon which GNU date is run. The The source of the
database is available here.
https://www.iana.org/time-zones
GNU date is operating upon the data from that database. That database
is updated often as it is a global compilation of every act of
governance and must be updated as the timezone rules are updated. In
the Debian and derivative software distributions I know this is
packaged in the 'tzdata' package.
> The date command has a number of switches, one of which is -d where you give it the number of seconds since epoch, as in "date -d <at> 1234" or "date --date @1234".
>
> Additionally, you can get it to return as any string you want to, as in "date -d <at> 1234 "+%c %z %Z"
>
> Both return "Thu Jan 1 01:20:34 BST 1970" or "Thu Jan 1 01:20:34 +0100 BST 1970" for the UK.
>
> /etc/localtime is set to /usr/share/zoneinfo/Europe/London.
>
> That's wrong, it should give "Thu Jan 1 00:20:34 1970 +0000 GMT".
>
> After all, in January, the UK is not in daylight saving time at the beginning of January.
And yet there it was! By an Act of Governance daylight saving time
was in effect at that time! No one is safe when the government is in
session. :-)
> It therefore gives you the current daylight saving time status,
> rather than what it should be at the time requested.
>
> I assume currently, this will give erroneous results for any
> requests in daylight saving.
Because date appears to be operating correctly I am closing this bug
ticket. But please we welcome that any discussion may continue in the
bug ticket.
Bob
This bug report was last modified 5 years and 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.