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 currently a "best-effort", depending on how much effort, time and money language and library implementers want to spend?
Is there a specific and complete implementation which could serve as a example for how time-related things should be handled?
Which existing library would you consider as a bad, a decent or a good example?
I don't think there's a single standard to such things at the moment, however there are multiple standards which such things may conform to: ISO 8601 for example.
ICU's own date/time handling is a cross-language (C/C++ and Java) and multi-platform library.
It handles dates and times internally, typically, using for a single time a UDate (C/C++) or a java.util.Date/long (Java), as number of milliseconds since 1-1-1970, or a Calendar object which is specific to the type of calendar (Gregorian vs Hijri, etc). Durations are available for formatting. Leap years are calculated as part of calendar systems, and leap seconds are assumed to be handled by the underlying operating system. DST/Timezone data is kept up to date with 'the tz database' sometimes referred to by its author's surname, Olson.
Hope this has answered your question some as regards ICU.
To answer your "Good Example" question, take a look at noda time - Jon Skeet's port of the JODA time libraries for Java to .Net - http://code.google.com/p/noda-time/wiki/Welcome?tm=6
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.
The library is documented very well, so I could probably assmble the entire answer from quotes, but I'll try to extract some fragments according to the template suggested by socs answer instead - nonetheless I'm going to start with an entire quote:
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.
The library supports 3 basic temporal types:
You can get a pretty intuitive overview on how the domain concepts relate to each other in section Details - Calculations.
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:
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.
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:
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.
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.
There are time(s) and there are dates (calendars)
The first problem is that dates are not linked to time but to astronomical position of Earh, Moon, etc. + regularity/periodicity of human activity. The time is also subjective and relative or even relativistic and measured either astronomically or or atomically.
The time bodies and the date/calendar bodies
The International Standartization Organization (ISO) [4] has issued
which, like other international standards, is recommendation and is based on already established practices.
It is (subjectively) based only on Gregorian Calendar [5] and on proleptic one (projected backwards to well before it was actually invented so is of limited use in dealing with historic dates) [5a].
The World Calendar Association [1d] initiated the introduction of new World Calendar since 2012 [1a-1d] which would make useless already existing date libraries. Again, the same main problem, see on it further on.
The most covering, I ever saw, date-time-related comparison in IT systems is [2] between BIG8 DBMS (IBM DB2, Informix, Ingres, InterBase, Microsoft SQL Server, MySQL, Oracle, and Sybase).
This and all other surveys show that the processing of the same, for ex., Gregorian calendar time/dates are different between all systems as well as inside the same platforms (between different products and versions of the same product), see for ex., [3].
THE MAIN PROBLEM with all date/time libraries in all-all systems, frameworks is that their date/time datatypes do not permit to include geographical and calendar information in date/time datatypes.
Without which they are mainly half- useless - what is the sense of milliseconds in SQL Server datetime2 values in 7th century? At that time there was even no clocks measuring time with accuracy of minutes (Galileo Galilei used, for ex., his heart beats to measure intervals of time in his experiments) as well as Gregorian Calendar was not even invented.
So, plenty of datetime type space is misused failing to give the most important flexibility of working with dates by linking and including with them to geography and/or calendar info.
Just fast illustrations:
==== Cited:
[1a]
World Calendar 2012: 35 days in a month
http://www.panorama.am/en/society/2010/01/29/newcalendar/
[1b] http://en.wikipedia.org/wiki/World_Calendar
[1c] http://www.theworldcalendarin2012.org/Index2.htm
[1d] http://www.theworldcalendar.org/TWCA.htm
[2] Peter Gulutzan,Trudy Pelzer. SQL Performance Tuning: Dates in SQL
http://www.informit.com/articles/printerfriendly.aspx?p=30939
[3] SqlDateTime.MinValue != C# DateTime.MinValue, why?
http://stackoverflow.com/questions/805770/sqldatetime-minvalue-c-datetime-minvalue-why
[4]
International Organization for Standardization
http://en.wikipedia.org/wiki/International_Organization_for_Standardization
[4a] ISO 8601 Data elements and interchange formats — Information interchange — Representation of dates and times
http://en.wikipedia.org/wiki/ISO_8601
[5]
Gregorian Calendar
http://en.wikipedia.org/wiki/Gregorian_calendar
[5a] Proleptic Gregorian calendar
http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
[5b] Gregorian Calendar Adoption
http://en.wikipedia.org/wiki/Gregorian_calendar#Adoption
[6]
http://en.wikipedia.org/wiki/Galileo_Galilei
You mention Python in an earlier comment.
Python's builtin datetime support (docs) is pretty practical, but you have to use a third-party timezone database such as pytz (docs) to make it close to complete. And, as the pytz docs mention, you may still have problems with adding deltas to times right around DST transitions if you aren't careful.
It was once the case that eGenix's mx.DateTime was the way to go if datetime didn't do it for your application, particularly for string to timestamp conversions, but dateutil seems to be popular these days (I haven't used it though).