At Larry's suggestion, I'm moving this over to info-cvs, from bug-cvs.
Larry Jones wrote:
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 19, 2000 2:02 PM
> To: Cameron, Steve
> Cc: [EMAIL PROTECTED]
> Subject: Re: patch to log.c to permit dates to be output in localtime
>
> 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.
[smc] Of course, I didn't really consider it an
argument anyway, just a discussion, I'm just
trying to understand how "cvs history -z" currently
wroks. .
> 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.
[smc] By portable fashion, you mean, wihtout
doing time_t arithmetic and without assuming
time_t's are in seconds, right?
So, how about this:
(I got some help from [EMAIL PROTECTED] on this)
mktime() taks as input a struct tm, which has
fields for year, month, day, hour, min, sec, and
it assumes localtime.
You can convert freely (if not obviously)
between a struct tm and a time_t, using
mktime to get time_t's and localtime()
or gmtime() to get struct tm's.
Now, if I choose a constant UTC time
carefully, I may find there's one, which when
converted into any timezone will not involve
any kind of complicated calculalations, (e.g.
no leap years, no crossing month boundaries,
no crossing year boundaries, etc.)
Using this specially chosen date, use
mktime to get a time_t, then use localtime
and gmtime to get struct tm's for local and UTC.
Because the date is specially chosen, only
the day, hour, minutes and seconds
need to be looked at, all the other usual
complications can be ignored. So
the number of seconds difference betwen
localtime and UTC can be calculated
without knowing what a time_t is by looking
at the differences between these to struct tm's
for this specially chosen date. (this
automatically handles daylight savings
time too.)
Send this number of seconds over to the
server as an ascii string.
(Now for my next trick.)
On the server side, use the date as found
in the log entry (for example) and construct
a struct tm from it. (trivial)
Next just add the number of seconds to
tm.tm_sec, According to the\ mktime() man
page, the seconds, as input, are not restricted
to 0-59. You can just add them all in, even if
it's multiple days worth of seconds.
Then let mktime do it's thing, and it will
magically make the correct time_t.taking
that possibly huge (or negatively huge)
tm_sec value into account. Then, convert
the resulting time_t back to a struct tm,
and there's your answer.
That's the theory anyway, I haven't tried it.
All the time_t arithmetic and hard
calendar algorithms are hidden inside
mktime(), or else avoided entirely by
using a carefully chosen date.
How does that sound?
-- steve
