parsedate.3: add an item in BUGS noting the weirdness of "next"
The real purpose of this commit is to supply the following message
which should be used for the immediately previous commit, replacing
its commit message (the two are similar, but definitely not the
same). With thanks to gdt@ for pointing out one of the (many) errors
in the previous message (and noting others I had already seen).
----
Make parsedate handle "12 noon" and "12 midnight" (including when the
time given is "12:00" or "12:00:00") - but only for exactly 12 o'clock.
"12:00:01" is am or pm, not noon or midnight.
"12 am" remains as an alias for "12 midnight", and "12 pm" for noon,
though both are strictly (pedanticly) invalid (and meaningless.)
Note that "12 midnight" (or "12 am") means 00:00:00 (ie: midnight at
the start of the day, not at the end.)
the time is "12:00" or "12:00:00) - but only for exactly 12 o'clock.
"12:00:01" is am or pm, not noon or midnight.
"12 am" remains as an alias for "12 midnight", and "12 pm" for midnight,
though both are strictly invalid (and meaningless.)
Note that "12 pm" means 00:00:00 (ie: midnight at the start of the
day, not at the end.)
If 06:00 or 18:00 are wanted, just say "06:00" (etc). If these
are ever added back, they really should determine location, and
calculate actual sunrise/sunset times for the location and date.
That's not likely to happen...
our Convert(). And check it for failure. This fixes three sets of
problems:
(1) depending on the passed-in value of Timezone it might
disassemble the time in one timezone and reassemble it in
another, causing mysterious offsets of a few hours;
(2) with the previous set of changes to this file, Convert() fails
if it ends up normalizing a date, so e.g. going three months
forward from March 31 would fail;
(3) previously if Convert() failed we passed -1 on to DSTcorrect(),
which made a mess.
PR 50574.
- Add validation to date/time strings by checking that mktime did not change
the fields of struct tm from the ones requested
- Allow the format "year monthname day".
From kre
- fix missing/inconsistent abbreviations
- set dst only if we are using localtime.
- properly check for errors where there were missing checks
- handle errno properly including saving and restoring.
* A magic value USE_LOCAL_TIME (defined as 99999) may be passed as the
Timezone to Convert(), instructing it to use mktime() to work
in the local time zone, instead of using mktime_z to work in UTC
(and then adding the specified timezone offset).
* Some old code is removed now that there's no need to find the local
timezone offset.
* Allow either one or both of the now and zone arguments to
parsedate() to be NULL, treating them independently. Previously,
if either one was NULL, the other was ignored.
* If the zone argument is specified, then the current date is calculated
in the specified zone, not in local time.
Also add some disabled debug code.
This should fix PR lib/47916.
a numeric timezone. Move some productions from "time" to "time_numericzone".
Increment yyHaveZone when encountering one of these.
Previously, input of the form "HH:MM:SS +ZZZZ" would not have set the
yyhaveZone flag.
that was designed for handling two-digit abbreviated years.
For example, "1/2/70" still refers to the year 1970, as before,
but "70-01-02" now refers to the year 70.
* Add a new yyHaveFullYear member to struct dateinfo, to record whether
or not the year needs to be adjusted.
* Code that parses years sets yyHaveFullYear=1 if they know that the
year should not be adjusted (as is the case for ISO 8601 dates), or if
they perform their own adjustment (as is the case for CVS timestamps).
* Move the year adjustment code into a new function, AdjustYear,
instead of inline in Convert().
* Make Convert() assume the year doesn't need to be adjusted,
and make Convert's callers first call AdjustYear() if appropriate.
setting tm_gmtoff doesn't work. Instead, call mktime_z(3)
with a null timezone (so it works in UTC) and adjust the
result afterwards. Now "date -d @0" correctly
prints the local equivalent of 1970-01-01 00:00:00 UTC.
Fix multiple issues:
- Remove bogus 2038 check and add overflow checks in the appropriate places.
- Correct incomplete leap year calculation that broke things after 2100.
- Check localtime return values
- Change int calculations to time_t to avoid oveflow.
- Consistently check/return -1 and remove bogus comment about not being
able to return -1.
Now:
$ date -d 20991201
Tue Dec 1 00:00:00 EST 2099
$ date -d 40991201
Tue Dec 1 00:00:00 EST 4099
$ date -d 10000000991201
Tue Dec 1 00:00:00 EST 1000000099
TIME=0:04.48 CPU=117.8% (5.288u 0.000s) SWAPS=0 (0+95)pf (0i+0o) (0Kc+0Kd)
$ date -d 100000000991201
date: Cannot parse `100000000991201'
TIME=0:53.48 CPU=99.2% (53.086u 0.000s) SWAPS=0 (0+96)pf (0i+0o) (0Kc+0Kd)
Exit 1
