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@1234" or "date --date > @1234". > > Additionally, you can get it to return as any string you want to, as in "date > -d@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
