Re: Can't set the timezone for "date".

[Alan Mackenzie]

Hi, James!

On Sun, Jul 22, 2007 at 11:11:54PM +0100, James Youngman wrote:
> On 7/22/07, Alan Mackenzie <address@hidden> wrote:
> >> Since you were editing the file manually try "Etc/GMT" instead of
> >> "GMT" and it should behave as you expect.  However I suggest using
> >> "UTC" instead of "GMT", as in "Etc/UTC".

> >I'll stick with "GMT", I think.  It describes the time zone for what
> >it is (the local time in a certain English village), rather than the
> >context in which it it used.

> No, the correct TZ value for that is Europe/London.  GMT as such
> doesn't really exist, and the nearest real thing to GMT is UTC.

<Takes a quick trip to wikipedia.>  OK, GMT doesn't "really exist", but
neither does SQRT(-1) or the ether.  I don't know what I wanted to say
here any more.  :-)

But "Europe/London" is essentially different from "GMT":  It implements
summer time.  I don't want summer time on my PC, even if the livin' is
easy.  ;-)  My PC was set up with "Europe/London" up until yesterday.

I started this thread due to suffering the embarrassment of somebody
pointing out the times in my emails were ~1.5 hours in the future.  1
hour of this somehow came from BST ("British Summer Time"), the other
half hour from Debian steadily advancing my CMOS clock over ~1 year by
splatting its system time into the CMOS at every shutdown.  I don't
understand the latter process and feel pretty peeved by it, but I'll calm
down after somebody on the debian list explains it to me.

The time mechanism on Linux is too complicated for my taste - I spent
most of yesterday morning trying to get my head round it, and it feels
like time lost rather than useful knowledge gained.  There are too many
binary choices interacting with eachother:  the CMOS time is either local
or UTC; we're in normal time or summer time; TZ is set or unset -
possibly more.  I would rather eliminate this complexity than deal with
it: so my CMOS (like my wristwatch) is set to "GMT", so is my
/etc/timezone, and now I don't have to cope with the vagaries of summer
time (like what happens when you send an email between 2 a.m. and 3 a.m.
in that critical Sunday morning in March?)

[ .... ]

> >Hmm.  That's a strange answer.  I'm interpreting it to mean that
> >"summer time" is outwith the scope of coreutils.

> Yes, precisely.

OK.  Presumably the point was talked through quite some while ago, but it
seems very strange to me.  It feels to me that the handling of TZ, summer
time, and so on, is an essentially "user level" feature, and
understanding it is an essential part of the "date" command.

> >I think it would be helpful if the manual said something like this.
> >Even coreutils.info just says (in a fairly buried place) "Normally,
> >`date' operates in the time zone indicated by `TZ', or the system
> >default if `TZ' is not set", without giving any indication of exactly
> >how $TZ indicates.  I found this unhelpful and frustrating.

> You could be right, there.   But the coreutils documentation does
> include a cross-reference to the libc documentation:-

OK.  My fault for not having a modern version of coreutils.info.  Older
versions didn't have this link.

>   Normally, `date' uses the time zone rules indicated by the `TZ'
> environment variable, or the system default rules if `TZ' is not set.
> *Note Specifying the Time Zone with `TZ': (libc)TZ Variable.

> The definition of the syntax and interpretation of $TZ belongs in the
> system documentation (in this case libc), not coreutils.

Again, that seems strange to me.  But I'll defer to coreutils's
maintainers here.

Thanks for the help!

> James.

-- 
Alan Mackenzie (Ittersbach, Germany).