Bug in Gnu date?

So as I write this today is two days after the clocks go back here in the UK. I have a script that worked last week. Yesterday it developed a bug. I eventually found the culprit is Gnu Date.

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial
$ date --version
date (GNU coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
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.

Written by David MacKenzie.
$ date --date="15:00"
Mon 29 Oct 15:00:00 GMT 2018
$ date --date="15:00 + 1 minute"
Mon 29 Oct 14:01:00 GMT 2018
$ date --date="15:00 GMT  + 1 minute"
Mon 29 Oct 15:01:00 GMT 2018

So given a time, Gnu date converts it in the local timezone. But apparently if you force date arithmetic on it Gnu date shifts into summertime. I haven't done a thorough investigation into how far this goes. A quick google search didn't find anything.

Has anyone else noticed this phenomenon? Can anyone else reproduce it? Is this a known bug, or should I notify the Gnu Date maintainers?

Andrew

I cannot reproduce on 8.4, on RHEL/Centos 6.7 or later.

$ date --date="15:00"
Tue Oct 30 15:00:00 CET 2018
$ date --date="15:00 + 1 minute"
Tue Oct 30 15:01:00 CET 2018

What does hwclock as root output, is it expected ?

Regards
Peasant.

$ sudo hwclock
Tue 30 Oct 2018 12:49:20 GMT  .265103 seconds
$ date
Tue 30 Oct 12:49:23 GMT 2018

Andrew

Can you show output of :

ls -lrt /etc/localtime
zdump -v /etc/localtime  | grep "2018" | grep "Oct"

I suspect it's normal behavior on gnu date due to daylight savings, and day having 25 hours.
This is what i've been reading on coreutils list.

Is this behavior still present or just happened on specified date ?

Regards
Peasant.

Nope, still going it today, Weds Oct 31st. Maybe it's a Halloween thing I'll try it again tomorrow.

Funnily enough I tested this on a Solaris 11 system I have access to, which has Gnu Date installed as /usr/bin/gdate , and it has the same problem. This version of gdate is 8.16.

Andrew

If i put GMT as well in date command, i get same result on every operating system which has gnu date, regardless of the version.

Sorry for the confusion.

Is there a reason you are using GMT in your command or ?

Regards
Peasant.

I haven't explicitly set anything to GMT. My locale is en_GB.utf8 hence:

$ date
Wed 31 Oct 11:49:43 GMT 2018
$ date --date='last week'
Wed 24 Oct 12:49:57 BST 2018

And, of course,

$ date +%Z
GMT

What I noticed was that the time, for some reason, was being manipulated as though it was in the timezone UTC+1 and then presented in GMT. If I then forced the time being manipulated to be in GMT I got the result I was expecting.

Thanks for your time in looking at this.

Andrew

Your timezone is not determined by your locale setting. What does the following command output:

echo $TZ

It's not set. However the file /etc/timezone contains the string Europe/London ; the file /usr/share/zoneinfo/Europe/London links to ../GB , ie /usr/share/zoneinfo/GB .

Or, more succinctly, I am using the default system timezone, which was set to Europe/London when I installed this system.

Andrew

I've found this message in the bug-coreutils list. It turns out that date is parsing the + 1 as offset from UTC. This can be seen if I use different numbers in my date invocation:

$ date --date="15:00   + 3 minutes"
Mon  5 Nov 12:01:00 GMT 2018
$ date --date="15:00 + 2 minutes"
Mon  5 Nov 13:01:00 GMT 2018
$ date --date="15:00 + 1 minute"
Mon  5 Nov 14:01:00 GMT 2018
$ date --date="15:00 - 1 minute"
Mon  5 Nov 16:01:00 GMT 2018
$ date --date="15:00 - 2 minutes"
Mon  5 Nov 17:01:00 GMT 2018
$ date --date="15:00 - 3 minutes"
Mon  5 Nov 18:01:00 GMT 2018

Notice how the minute field stays at 01 rather than being incremented (decremented) by the value I specified.
Now, counter-intuitively, I can place the + 1 minute anywhere in the date definition, so

$ date --date="+ 1 minute 15:00"
Mon  5 Nov 15:01:00 GMT 2018
$ date --date="+ 5 minutes 15:00"
Mon  5 Nov 15:05:00 GMT 2018
$

works as I wanted it to.

So, it is a (known) bug; it is not the bug I thought it was.

Time to mark as solved.

Andrew

Nice sleuthing, I can confirm this is still occurring in version 8.29.