Michael Stone wrote: > Bob Proulx wrote: > > The "locale independent format" looks to be the problem in the above > > to me. But I think that is only your command line test as that is > > different from what I see in the tzdata postinst. > > This is where I rant that the entire -d interface should be officially > deprecated because it is so broken, and replaced with something reliable > that doesn't implement a confusing mess of kinda-NLP.
I wish it had never been added to the date command! It is a partially
implemented hack that became one of the main coreutils. I would
rather something like that had been put into its own command. The
date command should have been left as solely setting the system date.
In a separate command it could have thrived. Then as superior ones
came along the better one could replace it. Survival of the fittest
and all of that. However when there is no choice there can be no
natural selection.
Ben Hutchings wrote:
> It's a bit late for that.
Agreed. I have never been one for burning down the house in order to
build a complete replacement. In my experience the replacements never
get done and usually turn out worse than the originals they were
intended to replace.
> Still, there should be clear documentation of which
> locale-independent input formats can be relied on (and they should
> be covered by regression tests).
Personally I like the 'date -R' format. It is unambiguous. It can be
both produced and parsed by the date command. And I also prefer
working entirely within the UTC timezone. It avoids any locale
specific differences and avoids DST gaps and overlaps.
As you know a 100% complete test suite is almost like a unicorn. We
desire them but they just don't exist. We are fortunate that the
coreutils does implement an extensive test suite. But it is
practically impossible to have 100% coverage.
Michael Stone wrote:
> > env TZ=Europe/London LC_ALL=C date -d "Sun Mar 27 00:59:00 UTC 2016"
> Sun Mar 27 00:59:00 GMT 2016
> > env TZ=Europe/London LC_ALL=C date -d "Sun Mar 27 01:00:00 UTC 2016"
> date: invalid date 'Sun Mar 27 01:00:00 UTC 2016'
Since I prefer the unambiguous -R format let me record the observation
using it.
On Sid with version 8.25:
env TZ=Europe/London LC_ALL=C date -R -d "Sun, 27 Mar 2016 00:59:59 +0000"
Sun, 27 Mar 2016 00:59:59 +0000
env TZ=Europe/London LC_ALL=C date -R -d "Sun, 27 Mar 2016 01:00:00 +0000"
date: invalid date 'Sun, 27 Mar 2016 01:00:00 +0000'
On Jessie with version 8.23:
env TZ=Europe/London LC_ALL=C date -R -d "Sun, 27 Mar 2016 00:59:59 +0000"
Sun, 27 Mar 2016 00:59:59 +0000
env TZ=Europe/London LC_ALL=C date -R -d "Sun, 27 Mar 2016 01:00:00 +0000"
Sun, 27 Mar 2016 02:00:00 +0100
Let's check the tzdata. Note that TZ=Europe/London produces GMT not
UTC. I am across the pond but AFAIK from looking at tzdata GMT has
Daylight Savings Time. Right? We always have DST problems around DST
changes.
zdump -v Europe/London | grep 2016
Europe/London Sun Mar 27 00:59:59 2016 UT = Sun Mar 27 00:59:59 2016 GMT
isdst=0 gmtoff=0
Europe/London Sun Mar 27 01:00:00 2016 UT = Sun Mar 27 02:00:00 2016 BST
isdst=1 gmtoff=3600
Europe/London Sun Oct 30 00:59:59 2016 UT = Sun Oct 30 01:59:59 2016 BST
isdst=1 gmtoff=3600
Europe/London Sun Oct 30 01:00:00 2016 UT = Sun Oct 30 01:00:00 2016 GMT
isdst=0 gmtoff=0
The tzdata show Europe/London transitioning from "Mar 27 00:59:59 2016
GMT" to "Mar 27 02:00:00 2016 BST". There is no 01:00:00 GMT in that
timezone.
But the reference datestamp is clearly UTC not GMT. In UTC as a
reference timestamp that should be okay. Let's poke at the problem
from a slightly different angle.
env TZ=Europe/London LC_ALL=C date -R -d @1459040399
Sun, 27 Mar 2016 00:59:59 +0000
env TZ=Europe/London LC_ALL=C date -R -d @1459040400
Sun, 27 Mar 2016 02:00:00 +0100
That works. Making me think it is simply parsing the date
incorrectly. By looking at this angle it looks like date is parsing
UTC as GMT instead of UTC. Need to look inside to see what is really
happening.
> Seems broken to me...
It does seem like it. Broken in 8.25 and working in 8.23. It will
need some dissection of the date code changes between.
Bob
signature.asc
Description: PGP signature
