On Mon, 2016-03-28 at 15:10 -0600, Bob Proulx wrote:
[...]
> 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.

GMT was the basis for UTC and is now defined as equal to it.  UK local
time is called "BST" when DST is in effect.

>   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.
[...]

Right, it seems to validate against the local timezone before it has
checked whether the string specifies another timezone.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to