Ben Hutchings wrote:
> $  readlink /etc/localtime
> /usr/share/zoneinfo/Europe/London

I assume that your locale is set to en_GB.UTF-8?  Could you provide
the output of locale so that we could see the other settings?  I am
interested in LC_TIME and LC_ALL particularly.

  locale

> $ date -d 00:59
> Sun 27 Mar 00:59:00 GMT 2016
> $ date -d "Sun 27 Mar 00:59:00 GMT 2016"
> date: invalid date ‘Sun 27 Mar 00:59:00 GMT 2016’

Unfortunately that input is not in a locale independent format.  That
is why it cannot be read by date in the above.  The date documentation
says this:

  ‘-d DATESTR’
  ‘--date=DATESTR’
       Display the date and time specified in DATESTR instead of the
       current date and time.  DATESTR can be in almost any common format.
       It can contain month names, time zones, ‘am’ and ‘pm’, ‘yesterday’,
       etc.  For example, ‘--date="2004-02-27 14:19:13.489392193 +0530"’
       specifies the instant of time that is 489,392,193 nanoseconds after
       February 27, 2004 at 2:19:13 PM in a time zone that is 5 hours and
       30 minutes east of UTC.
       Note: input currently must be in locale independent format.  E.g.,
       the LC_TIME=C below is needed to print back the correct date in
       many locales:
            date -d "$(LC_TIME=C date)"
       *Note Date input formats::.

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.

> $ date -d 02:00
> Sun 27 Mar 02:00:00 BST 2016
> $ date -d "Sun 27 Mar 02:00:00 BST 2016"
> date: invalid date ‘Sun 27 Mar 02:00:00 BST 2016’

I always recommend using 'date -R' to produce an unambiguous
representation.  This is an aside, but we are here.  Try this:

  TZ=Europe/London date -R -d 02:00
    Sun, 27 Mar 2016 02:00:00 +0100
  TZ=Europe/London date -R -d 'Sun, 27 Mar 2016 02:00:00 +0100'
    Sun, 27 Mar 2016 02:00:00 +0100

> This caused an upgrade of tzdata to fail for me.

It doesn't seem to me be a problem with date.  Looking briefly at the
tzdata postinst I see this:

  set -e
  ...
    TZBase=$(LC_ALL=C TZ=UTC0 date)
    UTdate=$(LC_ALL=C TZ=UTC0 date -d "$TZBase")
    TZdate=$(unset TZ ; LANG=C date -d "$TZBase")

Initially I don't see how that can fail but I may be missing
something.  Can you provide any more information?

I am probably missing something but I don't see a way for it to fail.

    TZBase=$(LC_ALL=C TZ=UTC0 date)

That sets LC_ALL=C and therefore will have the standard format.
(I wish it used date -R format instead.)

    UTdate=$(LC_ALL=C TZ=UTC0 date -d "$TZBase")

Same there.  It consumes the previous output which is in the standard
format so should parse okay.

    TZdate=$(unset TZ ; LANG=C date -d "$TZBase")

Here this makes me somewhat nervous because it sets LANG=C but either
LC_ALL or LC_TIME could override that setting.  But trying to trip a
problem there yielded nothing for me.

In the above LC_ALL=C will cause TZBase and UTdate to be in this
format:

  LC_ALL=C TZ=UTC0 date -d 'Sun, 27 Mar 2016 02:00:00 +0100'
    Sun Mar 27 01:00:00 UTC 2016

  LC_ALL=C TZ=UTC0 date -d 'Sun Mar 27 01:00:00 UTC 2016'
    Sun Mar 27 01:00:00 UTC 2016

That looks to be okay.  And the final date call:

  (unset TZ ; LANG=C date -d "Sun Mar 27 01:00:00 UTC 2016")
    Sat Mar 26 19:00:00 MDT 2016

  (unset TZ ; LC_ALL=en_GB.UTF-8 LANG=C date -d "Sun Mar 27 01:00:00 UTC 2016")
    Sat 26 Mar 19:00:00 MDT 2016

  (unset TZ ; LC_TIME=en_GB.UTF-8 LANG=C date -d "Sun Mar 27 01:00:00 UTC 2016")
    Sat 26 Mar 19:00:00 MDT 2016

In all three cases it was able to parse that date string okay.  I wish
it set LC_ALL instead of LANG however so as to remove any doubt.

What am I missing?

Bob

Attachment: signature.asc
Description: PGP signature

Reply via email to