Hi Bruce,
> I think that there lies madness. Is the duration that someone is trying to
> express necessarily starting from now? The primary intent was for stuff
> like:
>
> timeout --duration='xxxxxxxx' some-command
>
> which is, indeed, meaning "from now". So, if this were to somehow become
> widely used, it would be clearly incorrect to specify that some activity
> was to happen a certain duration after an event of some sort, and have
> "month" mean something different depending upon when that event happened
> to happen. That then raises the question of, "Why is anyone worrying over
> durations that so far exceed a day that using months is important?"
>
> For this context, the right, proper and easiest solution is to say that
> months are 30 days and leave it at that.
I tend to agree. Defining "1 month" as the time difference between
"1 month from now" and "now" leads to madness: What is "1 month" at
2009-01-31 08:37 ? 2009-02-31 does not exist...
But it should be documented.
> I did omit weeks in the last post. So, posting again -- this time for
> sure.... :)
This last attachment was missing. So I'm going to comment the previous code:
> It is much more forgiving than the ISO-8601 spec. It doesn't worry
> about counts being lower than the container size. The result just
> has to fit in a time_t value. So there are lots of ways:
>
> PyyyymmddThhmmss
> P nnnn Y nn M nn D T nn H nn M nn S
> nn d HH:MM:SS
> SSSS
> MMM:SS
Nice!
> Durations are a component of time intervals ...
Quoting 50 lines of wikipedia would IMO require to put the result under GFDL,
and the GFDL being incompatible to the GPL, you cannot do that. Can you
summarize the text instead of quoting it literally?
The module would need the usual gnulib structure: a .h file, a module
description, and - especially for a function with many possible inputs like
this one - a unit test.
> val = strtoul(pz, (char **)&pz, 10);
GNU coding style wants a space between the function name and the opening
parenthesis.
> while (isspace((int)*pz)) pz++;
Do you really mean that the result is locale dependent? Namely, if the user
uses U+00A0 (NO-BREAK SPACE) as a separator, he will get a parse success in
ISO-8859-1 locales but a parse failure in UTF-8 locales. - The gnulib module
'c-ctype' contains functions that don't have this problem.
> if (! isdigit((int)*in_pz)) goto bad_time;
Arguments of <ctype.h> functions need to be casted from 'char' to
`unsigned char', not to 'int'. A cast from 'char' to 'int' is a no-op.
> parse_YMD(char const * pz)
> {
> time_t res = 0, val;
> char * ps = strchr(pz, 'Y');
'ps' should be declared as 'char const *', because 'pz' has const.
Bruno
