How do libraries in different programming languages handle Date & Time, Timestamps & Durations, Leapseconds & -years, DSTs & Timezones, …?

Question

Is there a standard body or a specific normative way how time-related things should be implemented in practice (like ICU for Unicode-related tasks) or is this curre

Answer 1

I haven't used it in a while, but from past experience I'd say that Boost.Date_Time is a pretty good example.

While probably not the first choice for many fast paced projects today, the expressive power of C++ still seems to be a very good match for a complex problem domain like date/time, so combined with the high quality peer review process to pass for becoming an official Boost C++ library I'd hope that the library at hand could serve as a example for how time-related things should be handled, albeit not as a complete implementation, see below.

Boost Date Time

The library is documented very well, so I could probably assemble the entire answer from quotes, but I'll try to extract some fragments according to the template suggested by soc's answer instead - nonetheless I'm going to start with an entire quote:

Motivation

The motivation for this library comes from working with and helping build several date-time libraries on several projects. [...]

Programming with dates and times should be almost as simple and natural as programming with strings and integers. Applications with lots of temporal logic can be radically simplified by having a robust set of operators and calculation capabilities. Classes should provide the ability to compare dates and times, add lengths or time durations, retrieve dates and times from clocks, and work naturally with date and time intervals.

Domain Concepts

The library supports 3 basic temporal types:

• Time Point - Specifier for a location in the time continuum.
• Time Duration - A length of time unattached to any point on the time continuum.
• Time Interval - A duration of time attached to a specific point in the time continuum. Also known as a time period.

Calculations

You can get a pretty intuitive overview on how the domain concepts relate to each other in section Details - Calculations.

Constraints

An important part of my original decision to evaluate the library has been the available documentation of design goals and necessary tradeoffs in light of the complex problem domain, which seems to outline the real world expertise that has been put into the library - you can read more about it in the following two sections:

• Design Goals
• Tradeoffs: Stability, Predictability, and Approximations

Working with Timezone and DST data

There is full support for all kind of calculations and conversions one could think of, as far as I'm concerned - see the headings in section Examples for an initial impression.

Calendar/Time systems

This is definitely the weak spot concerning your specification, despite the library being specifically designed with extensibility in mind:

A large part of the genesis of this library has been the observation that few date-time libraries are built in a fashion that allows customization and extension. A typical example, the calendar logic is built directly into the date class. Or the clock retrieval functions are built directly into the time class. These design decisions usually make it impossible to extend or change the library behavior. At a more fundamental level, there are usually assumptions about the resolution of time representation or the gregorian calendar.

However, I'm not aware of any implementations of other calendar/time systems than the ones included, see Library Reference for the current implementations of:

• Date Time
• Gregorian
• Posix Time
• Local Time

Formatting and Parsing

This is fully supported and one of the strong points of the library due to the respective power of the underlying C++ I/O system, see Date Time Input/Output - the stream oriented C++ I/O has both merit and issues depending on your needs and expectations, but this topic is discussed elsewhere on this site.

Integration

This is provided as well via compatibility with Boost Serialization, which is archive oriented though, usually meaning a file of binary data, text data, XML or so; i.e. databases are not explicitly supported as in your JSR 310 example.