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