time.h design issues

[Paul Hill]

Dan and Scott,

"D. J. Bernstein" wrote:
> > An alternative API _might_ 
> 
> Who cares? Remember that the point of libtai is to support real
> programs, not to build an API in the sky.

I figure that I need an API that:
(1) cleanly calculates all the parts of the date and time it knows
about, 
(2) could be reasonably extended or leveraged to cover the "clerical
curiosities" of keeping and calculating values related to dates and
times.

While this could lead to API in the sky, it is also worth considering
the possibilities even for the core API that any API in the sky uses.

> > 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.
> 
> Why would a program want to refer to specific weekdays, rather than
> having a table of all the weekdays?

A Table?  For what?  This is a comment about your code using "magic
numbers", that is all.  If you provide a header that defines SUNDAY,
I don't need to know or care and any maintenance programmer doesn't
need to know or care whether the usage in your code is SUNDAY=0 or
SUNDAY=1, or SUNDAY=7.

> > I hope that is with or without consideration for local TZ.
> 
> What are you talking about? The Gregorian calendar does not depend on
> your local time zone.

Sorry, my mistake, I'm so used to thinking about date and time
together. In such cases TZ does matter.

Scott Harrington wrote:

> Simulation and real-time programs, for instance in the financial arena,
> need to know about past, present, and future offsets and DST rules for
> locales all around the world.  Nothing infuriates me more than seeing
> "US rules" hardcoded in some supposed timezone helper class; this is the
> whole reason the tz list exists.
> 
> I'll grant you that there are not a lot of us who demand conversions to
> and from lots of "local" time zones, over spans of many years, in a
> single (possibly multi-threaded) performance-sensitive application.  But
> these are "real programs".

Allow me to suggest a scenerio which just needs the latest TZ/DLS
changes,
but may be more common than just "simulation and real-time".
My experience suggests that as more organizations cover more than
one timezone and more business is done in a cooperative manner 
between some branch office and come central location, there is more
need to make sure every processs knows the correct and same 
TZ rules for all TZs involved in any of the data.

Consider for example, a multithreaded server at some corporate central
location that is taking information from remote locations each
night after closing time (client local time). Also consider
that not all uses of dates and times can be converted to server time,
client time, UTC time; there can be a mix of all of them.  Therefore
this rather pedestrian example of a corporate server taking
remote data would want to be able know all the TZs it is dealing
with well, and be able to handle them in a multi-threaded environment.
Plus the client (branch office) machine also might need to deal with
date and time conversions between various zone depending on what
it was sending. Even if it was not doing these date conversions
in a multi-threaded or real-time environment.

I only give this example to show that there is plenty of need 
in ordinary information processing applications for good TZ based
date/time calculations in a multi-threaded environment.

cheers,
-Paul