Cameron, Steve writes:
>
> [smc] So I just took a look at it. You seem to specify the
> timezone
> explicitly on the command line..., is there ary portable way
> to say "the local timezone, whatever that might be"
Yes, "LT" (case insensitive) is interpreted as "local time" (although,
in the client/server case, I think it's the server's local time).
> Hmm, on unixware 7, $TZ for me is ":US/Central", but on AIX,
> "CST6CDT",
> so that might not really work well depending on the client's
> and server's
> notions of what timezone names are...., So, the user must
> know what
> his local timezone is called on the remote server.
The way -z is currently implemented, you can specify anything for the
timezone that getdate() will take, which need not have anything
whatsoever to do with how the system represents timezones.
Please note that I'm not trying to imply that the current -z
implementation is good and should be emulated; on the contrary, there
are some things that seem wrong to me: LT should clearly be the client's
local time, not the server's, and there's no way to get Standard Time /
Daylight Saving Time switching for zones other than LT. I'm simply
arguing for consistency.
Correctly doing the conversion on the server side would require passing
all of the timezone information -- including the Daylight Saving Time
rules -- from the client to the server in some kind of portable fashion,
which I currently don't know of any way to do. Doing this right is a
hard problem (which is probably why no one's done it yet) -- I encourage
you to study it carefully and discuss it in info-cvs to find out what
people really want and/or need. (I personally see little need for
arbitrary timezones; allowing just UTC or local time would undoubtedly
make a complete and consistent implementation a lot easier.)
-Larry Jones
These things just seem to happen. -- Calvin
