| #
133381 |
|
09-Aug-2004 |
yar |
Change the behaviour of `-v' so that, e.g., stepping a month back
on March 31 won't take you to March 2 or 3 (now the result will
be the last day of February.)
In general, now stepping by months from the last days of the current
month A will take you to the very last day of the target month B if
B is shorter than A.
The previous version would just step to March 31 and rely on mktime(3)
to correct the date. Despite its simplicity, such way was counter-intuitive
to users and caused pain to shell script writers.
Noticed by: Igor Timkin <ivt at gamma dot ru>
Approved by: brian
MFC after: 2 weeks
|
| #
59022 |
|
04-Apr-2000 |
brian |
Always give mktime a timeval with tm_isdst set to -1, otherwise
things get a bit out-of-phase when we step backwards 1 hour from
between 0:00 and 1:00 on the first of the month following the
transition into Summer time. This is probably actually a bug
in mktime().
PR: 10963
If mktime() fails and 68 < year < 138, assume that the reason is
because of Summer time and adjust up or down according to our
adjusting context by one hour. This assumes that all DSTs are
multiples of 1 hour.
PR: 6223, 17750
|
| #
46073 |
|
25-Apr-1999 |
imp |
First set of fixes to keep egcs happy. These include {} around single
statement if blocks[*] when the else could be ambiguous, not defaulting
to int type and removal of some unused variables.
[*] This is explicitly allowed by style(9) when the single statement
spans more than one line.
Reviewed by: obrien, chuckr
|