[EMAIL PROTECTED] writes:
> 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.
That advice is admirable but is quite rarely followed. In practice,
people almost invar
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
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
cool, that's all I wanted to determine with the patch.
but the implementation isn't quite right.
I
[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 i
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Q1. Why is there a difference in the parsing of $TZ
and --date ... timezone ?
Q2. Why is a warning not printed when an invalid $TZ is set?
$ TZ=America/Los_Angeles date
Wed Mar 31 07:21:51 PST 2004
Missing info:
$date --date "09:00 America/L
