time.h design issues

[Paul Hill]

"D. J. Bernstein" wrote:
> 
> Here are easy answers to Paul Hill's date-calculation challenges using
> libtai's date functions. caldate_mjd() converts from a calendar date to
> the traditional MJD number, and caldate_frommjd() converts back.

I hope that is with or without consideration for local TZ.  I'll assume
that is what the last argument is for in caldate_frommjd().

BTW, is there some description of your API on the WWW somewhere?

> > exactly two months before now,
> 
> In my experience, as illustrated previously on this mailing list, people
> who use that phrase don't know what they're talking about. 

Why is that?  I was just listing examples, but I see you are already
into 
insults; can we keep it civilized please?  (At least hedge your bets by
using the phrase "most people") The question is what does the
person who request that particular value want it for and is it
actually useful in their application.  You will notice I listed it 
"after 60 days from now", hopefully you saw that as a contrast to 
variable lengths months which you took into consideration.

Since you think people do mess it up, all the more reason to
include such things in some library somewhere.  Now that library
could be a second level on top of one of the various proposals we see
here.
Yet, it is just such clerical time-keeping curiosities which I have 
found need to be quick to do with any base library.  It is the need
to ask questions about the calendar that is in the base libraries that
causes me to see weaknesses in some APIs

(I see that Paul E. has already responded that maybe exposing some of 
that info might be a good service.)

>> the last Thursday in November,
>
>cd.month = 12;
>cd.day = 1;
>day = caldate_mjd(&cd);
>do
>  caldate_frommjd(&cd,--day,&weekday,0);
>while (weekday != 4);

Why does the weekday stumble out some "side door" and is
not part of the standard data structure?

I would expect someone who extends a standard library to 
extend the standard structure and just add more to it, i.e.
adding business quarters, fiscal years, fiscal months, pay 
periods or whatever, to the end of a better tm struct (like tm from
http://www.cl.cam.ac.uk/~mgk25/c-time/) What is so special
about day of week?

I'm underwhelmed by the need when using your API to put
together and take apart a MJD and all fields, once for each day
just to walk back to a nearby weekday.
An alternative API _might_ provide a set of fields
(again like tm in Markus' and Paul E's API)
that could include day of week and week of month and then be
willing to figure the MJD from whatever is provided.
I'll admit most of the worst relatative dates
calculations can be figured out slowly and
then remembered as MJD or a date/time, but not all.

I would also hope that that any header file would define
SUNDAY, MONDAY, TUESDAY etc. so I don't have to know
the convention, even if there is an ISO standard.
The same applies for the months: JANUARY, FEBRUARY etc.

-Paul