| 1.5 |
| 08-Feb-2024 |
kre | Properly implement the POSIX format -d option.
Previously we have hacked that using parsedate(3) - but parsedate()
returns a time_t and consequently while it "handles" fractional seconds,
all that meant (all it really can mean) is that they're ignored.
The POSIX spec expects that (at least if the filesystem supports them)
fractional seconds can be set using the -d option.
Handle that by first attempting to parse the -d arg as a posix format
date-time string (using a reasonably strict parser), and if that fails,
then fall back on parsedate(3) to parse the arg.
If the posix format parse succeeds, the result will be the same as
parsedate(3) would return for the same string - except any fractional
seconds will be handled properly. If it fails, then nothing changes
from what we currently do.
Note the POSIX string is
YYYY-MM-DDThh:mm:ss[.frac][Z]
where YYYY is (at least) 4 digits (leading 0's are acceptable if
you really must!) all the MM DD hh mm ss fields are exactly 2
digits, T is either 'T' or ' ', '.' is either itself, or ',',
and 'frac' is one or more digits. Z (if given) is 'Z'. The
[.,]frac and Z fields are optional. Specify a time in a
slight shorthand like 2024-2-8T7:44:20 and the POSIX parse
will fail, leaving parsedate() to handle that (which it should).
But any fractional seconds which were given would be ignored.
Doc update coming - note the doc will call the YYYY field CCYY
instead, that's just a convenience to make other parts of what
is there make more sense - it is still one 4 (or more) digit field.
This should be an almost invisible change.
|
