Paul Eggert wrote:
[EMAIL PROTECTED] writes:
OK I've attached a patch that addresses question 1 above.
Note this is not for merging, just for disussion really.
The user-interface change sounds good, but the implementation isn't
quite right. You need to temporarily set TZ all the while mktime is
being run; it isn't correct merely to try to find the current UTC
offset for the time zone, as the UTC offset may be different at the
requested date than it is currently (due to political change, or
daylight-saving time, or whatever).
Also: Don't rely on snprintf (use asnprintf instead). Don't use
tzname or timezone (they're not portable, and besides you don't need
them once you get TZ and mktime right). Avoid arbitrary limits like
256, as POSIX time zone names can be arbitrarily long (and, while
we're on the subject TZ can contain "<", ">", "-", "+", and digits;
for details see
<http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_03>
and look for TZ).
Finally, the change needs to be documented accurately and clearly in
doc/getdate.texi. (This is perhaps the hardest part. :-)
Right I haven't been able to look at this for over 4 months :-(
Anyway looking at both of:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_03
`info libc "TZ Variable"`
suggests that implementation dependent TZs should start with a colon.
So I propose to only support that in date. for e.g.
date --date "09:00 :America/Los_Angeles"
That will still leave it symmetric with glibc for e.g.
TZ=:America/Los_Angeles date
This begs the question though of, why does tzselect
not prepend a colon to the returned TZ variable?
Looks like a buglet to me.
cheers,
Pádraig.
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
