Durations

Durations represent a length of time and can have positive and negative values. It is frequently useful to be able to perform calculations with other durations and with simple integral values. The following describes these calculations:

Intervals (Periods)

Interval logic is extremely useful for simplifying many 'calculations' for dates and times. The following describes the operations provided by periods which are based on half-open range. The following operations calculate new time periods based on two input time periods:

Special Value Handling

For many temporal problems it is useful for Duration and Timepoint types to support special values such as Not A Date Time (NADT) and infinity. In general special values such as Not A Date Time (NADT) and infinity should follow rules like floating point values. Note that it should be possible to configure NADT based systems to throw an exception instead of result in NADT.

the use of Julian Day number and the conversion between this and the Gregorian/Julian calendar date

Allow for flexible adjustments including leap seconds

Date Calculations

Provide tools for date calculations

provide basis for calculation of complex event specs like holidays

calendar to calendar conversions

provide for ability to extend to new calendar systems

Time Calculations

Provide concrete classes for manipulation of time

provide the ability to handle cross time-zone issues

provide adjustments for daylight savings time (summer time)

Clock Interfaces

Provide classes for retrieving time current time

access to a network / high resolution time sources

retrieving the current date time information to populate classes

I/O Interfaces

Provide input and output for time including

multi-lingual support

provide ISO8601 compliant time facet

use I/O facets for different local behavior

Tradeoffs: Stability, Predictability, and Approximations

Unavoidable Trade-offs

The library does its best to provide everything a user could want, but there are certain inherent constraints that limit what any temporal library can do. Specifically, a user must choose which two of the following three capabilities are desired in any particular application:

exact agreement with wall-clock time

accurate math, e.g. duration calculations

ability to handle timepoints in the future

Some libraries may implicitly promise to deliver all three, but if you actually put them to the test, only two can be true at once. This limitation is not a deficiency in the design or implementation of any particular library; rather it is a consequence of the way different time systems are defined by international standards. Let's look at each of the three cases:

If you want exact agreement with wall-clock time, you must use either UTC or local time. If you compute a duration by subtracting one UTC time from another and you want an answer accurate to the second, the two times must not be too far in the future because leap seconds affect the count but are only determined about 6 months in advance. With local times a future duration calculation could be off by an entire hour, since legislatures can and do change DST rules at will.

If you want to handle wall-clock times in the future, you won't be able (in the general case) to calculate exact durations, for the same reasons described above.

If you want accurate calculations with future times, you will have to use TAI or an equivalent, but the mapping from TAI to UTC or local time depends on leap seconds, so you will not have exact agreement with wall-clock time.

Stability, Predictability, and Approximations

Here is some underlying theory that helps to explain what's going on. Remember that a temporal type, like any abstract data type (ADT), is a set of values together with operations on those values.

Stability

The representation of a type is stable if the bit pattern associated with a given value does not change over time. A type with an unstable representation is unlikely to be of much use to anyone, so we will insist that any temporal library use only stable representations.

An operation on a type is stable if the result of applying the operation to a particular operand(s) does not change over time.

Predictability

Sets are most often classified into two categories: well-defined and ill-defined. Since a type is a set, we can extend these definitions to cover types. For any type T, there must be a predicate is_member( x ) which determines whether a value x is a member of type T. This predicate must return true, false, or dont_know.

If for all x, is_member( x ) returns either true or false, we say the set T is well-defined.

If for any x, is_member( x ) returns dont_know, we say the set T is ill-defined.

Those are the rules normally used in math. However, because of the special characteristics of temporal types, it is useful to refine this view and create a third category as follows:

For any temporal type T, there must be a predicate is_member( x, t ) which determines whether a value x is a member of T. The parameter t represents the time when the predicate is evaluated. For each xi, there must be a time ti and a value v such that:

v = true or v = false, and

for all t < ti, is_member( xi, t ) returns dont_know, and

for all t >= ti, is_member( xi, t ) returns v.

ti is thus the time when we "find out" whether xi is a member of T. Now we can define three categories of temporal types:

If for all xi, ti = negative infinity, we say the type T is predictable.

If for some xi, ti = positive infinity, we say the type T is ill-formed.

Otherwise we say the type T is unpredictable (this implies that for some xi, ti is finite).

Ill-formed sets are not of much practical use, so we will not discuss them further. In plain english the above simply says that all the values of a predictable type are known ahead of time, but some values of an unpredictable type are not known until some particular time.

Stability of Operations

Predictable types have a couple of important properties:

there is an order-preserving mapping from their elements onto a set of consecutive integers, and

duration operations on their values are stable

The practical effect of this is that duration calculations can be implemented with simple integer subtraction. Examples of predictable types are TAI timepoints and Gregorian dates.

Unpredictable types have exactly the opposite properties:

there is no order-preserving mapping from their elements onto a set of consecutive integers, and

duration operations on their values are not stable.

Examples of unpredictable types are UTC timepoints and Local Time timepoints.

We can refine this a little by saying that a range within an unpredicatable type can be predictable, and operations performed entirely on values within that range will be stable. For example, the range of UTC timepoints from 1970-01-01 through the present is predictable, so calculations of durations within that range will be stable.

Approximations

These limitations are problematical, because important temporal types like UTC and Local Time are in fact unpredictable, and therefore operations on them are sometimes unstable. Yet as a practical matter we often want to perform this kind of operation, such as computing the duration between two timepoints in the future that are specified in Local Time.

The best the library can do is to provide an approximation, which is generally possible and for most purposes will be good enough. Of course the documentation must specify when an answer will be approximate (and thus unstable) and how big the error may be. In many respects calculating with unpredictable sets is analogous to the use of floating point numbers, for which results are expected to only be approximately correct. Calculating with predictable sets would then be analogous to the user of integers, where results are expected to be exact.

For situations where exact answers are required or instability cannot be tolerated, the user must be able to specify this, and then the library should throw an exception if the user requests a computation for which an exact, stable answer is not possible.

Terminology

The following are a number of terms relevant to the date-time domain.

A taxonomy of temporal types:

Timepoint -- Specifier for a location in the time continuum. Similar to a number on a ruler.

Timelength -- A duration of time unattached to any point on the time continuum.

Timeinterval -- A duration of time attached to a specific point in the time continuum.

And some other terms:

Accuracy -- A measure of error, the difference between the reading of a clock and the true time.

Calendar System -- A system for labeling time points with day level resolution.

Clock Device -- A software component (tied to some hardware) that provides the current date or time with respect to a calendar or clock system.

Precision -- A measure of repeatability of a clock.

Resolution -- A specification of the smallest representable duration (eg: 1 second, 1 century) for a clock/calendar system or temporal type.

Stability -- The property of a class which says that the underlying representation (implementation) associated with a particular (abstract) value will never change.

Time System -- A system for labeling time points with higher resolution than day-level.

Some standard date-time terminology:

Epoch -- Starting time point of a calendar or clock system.

DST -- Daylight savings time - a local time adjustment made in some regions during the summer to shift the clock time of the daylight hours

Time zone -- A region of the earth that provides for a 'local time' defined by DST rules and UT offset.

UTC Time -- Coordinated Universal Time - Civil time system as measured at longitude zero. Kept adjusted to earth rotation by use of leap seconds. Also known as Zulu Time. Replaced the similar system known as Greenwich Mean Time. For more see http://aa.usno.navy.mil/faq/docs/UT.html

Time Label -- A tuple that either completely or partially specifies a specific date-time with respect to a calendar or clock system. This is the year-month-day representation.

Adjusting Time Length -- A duration that represents varying physical durations depending on the moment in time. For example, a 1 month duration is typically not a fixed number of days and it depends on the date it is measured from to determine the actual length.

These are design sorts of terms:

Generation function -- A function that generates a specific set of time points, lengths, or intervals based on one or more parameters.

References

The design of the library is currently being evolved using Wiki and email discussions. You can find more information at: Boost Wiki GDTL Start Page.

Build-Compiler Information

Overview

The library has a few functions that require the creation of a library file (mostly to_string, from_string functions). Most library users can make effective use of the library WITHOUT building the library, but simply including the required headers. If the library is needed, the Jamfile in the build directory will produce a "static" library (libboost_date_time) and a "dynamic/shared" library (boost_date_time) that contains these functions.

Compilation Options

By default the posix_time system uses a single 64 bit integer internally to provide a microsecond level resolution. As an alternative, a combination of a 64 bit integer and a 32 bit integer (96 bit resolution) can be used to provide nano-second level resolutions. The default implementation may provide better performance and more compact memory usage for many applications that do not require nano-second resolutions.

To use the alternate resolution (96 bit nanosecond) the variable BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG must be defined in the library users project files (ie Makefile, Jamfile, etc). This macro is not used by the Gregorian system and therefore has no effect when building the library.

As of version 1.33, the date_time library introduced a new IO streaming system. Some compilers are not capable of utilizing this new system. For those compilers the earlier ("legacy") IO system is still available. Non-supported compilers will select the legacy system automatically but the user can force the usage of the legacy system by defining USE_DATE_TIME_PRE_1_33_FACET_IO.

As a convenience, date_time has provided some additional duration types. Use of these types may have unexpected results due to the snap-to-end-of-month behavior (see Reversibility of Operations Pitfall for complete details and examples). These types are enabled by default. To disable these types, simply undefine BOOST_DATE_TIME_OPTIONAL_GREGORIAN_TYPES in your project file.

Another convenience is the default constructors for date, and ptime. These constructors are enabled by default. To disable them, simply define DATE_TIME_NO_DEFAULT_CONSTRUCTOR in your project file.

Compiler/Portability Notes

The Boost Date-Time library has been built and tested with many compilers and platforms. However, some compilers and standard libraries have issues. While some of these issues can be worked around, others are difficult to work around. The following compilers are known to fully support all aspects of the library:

Codewarrior 9.4 Windows

GCC 3.2 - 3.4, 4.x on Linux

GCC 3.3, 4.x on Darwin

GCC 3.3 - 3.4, 4.x on Solaris

GCC 3.3, 4.x on HP-UX

QCC 3.3.5 on QNX

MSVC 7.1 Windows

Intel 8.1-9.x Linux and Windows

Unfortunately, the VC8 compiler has some issues with date-time code.
The most serious issue is a memory leak which was introduced into the
VC8 standard library basic_stream code. Date-time has code has been changed
to avoid this as much as possible, but if you are using the legacy IO option
(NOT the default with VC8) then the issue can still arise. See the
mailing list archive for more details.

In addition to the problem above, some versions of the VC8 library have limited
the range of allowed
values in the std::tm structure to positive values. This was a new
restriction added in the VC8. The effect is that dates prior to the year
1900 will cause exceptions. There is, unfortunately, no easy workaround for
this issue. Note that the new 64bit version of the VC8 compiler
does not appear to have this limitation.

These compilers support all aspects of the library except wstring/wstream
output.

MinGW 3.2, 3.4, 3.5 *

GCC 3.2 (cygwin) *

In particular, a lack of support for standard locales limits the ability of the library to support iostream based input output. For these compilers a set of more limited string based input-output is provided. Some compilers/standard libraries with this limitation include:

Borland 5.6

Official support for some older compilers has now been dropped. This includes:

GCC 2.9x

Borland 5.1.1

MSVC 7.0 and 6 SP5

Visual Studio & STLPort

There is a known issue with Visual Studio (7.0 & 7.1) and STLPort. The build errors typically make reference to a type issue or 'no acceptable conversion' and are attempting to instantiate a template with wchar_t. The default build of STLPort does not support wchar_t. There are two possible workarounds for this issue. The simplest is the user can build date_time with no wide stream/string etc. The other is to rebuild STLPort with wchar_t support.

To build date_time with no wide stream/string etc, execute the following command from $BOOST_ROOT:

Tests

directories. Building and executing these tests assures that the installation is correct and that the library is functioning correctly. In addition, these tests facilitate the porting to new compilers. Finally, the tests provide examples of many functions not explicitly described in the usage examples.

Change History

Changes from Boost 1.41 to 1.44 (date_time 1.08 to 1.09)

Type

Description

Bug fix

The "%T" and "%R" format specifiers are now processed by the library rather than underlying standard facet.
This fixes the cases when the placeholders are not supported by the facet
(#3876).

Changes from Boost 1.40 to 1.41 (date_time 1.07 to 1.08)

Type

Description

Change

The default format for time durations is now "%-%O:%M:%S%F" instead of "%-%H:%M:%S%F" that was used previously. In order to retain the old behavior, the format string has to be specified explicitly during the time IO facet construction (#1861).

Changes from Boost 1.38 to 1.40 (date_time 1.06 to 1.07)

Changes from Boost 1.34 to 1.38 (date_time 1.05 to 1.06)

Type

Description

Feature

Added support for formatting and reading time durations longer than 24 hours.
A new formatter %O is used indicate such long durations in the
format string. The old %H format specifier is thus restricted
to represent durations that fit into two characters, in order to retain support
for reading durations in ISO format. In case if it is detected that the %H
format specifier is used with longer durations, the results are not specified
(an assertion in debug builds is raised).

Bug fix

Added support for GCC 4.3. Several compilation issues were solved, as well as
compiler warnings were taken care of.

Bug fix

Added missing streaming operators for the local_time_period class.

Bug fix

Added several missing includes in different places. Some includes that are
not needed in some configurations were made conditional.

Bug fix

Solved compilation problem that was caused by not finding streaming operators
for gregorian::date_duration via ADL. The type is now made actually
a class rather a typedef for the date_time::date_duration template.
The similar change was done for gregorian::weeks.

Bug fix

Added a correctly spelled date_time::hundredth time resolution enum
value. The old one date_time::hundreth is considered deprecated and
to be removed in future releases.

Bug fix

Fixed compilation error in format_date_parser.hpp because of incorrect
stream type being used.

Bug fix

On Windows platform made inclusion of windows.h optional. The header is only used
when the BOOST_USE_WINDOWS_H macro is defined. Otherwise (and by default),
the library uses internal definitions of symbols from this header.

Bug fix

On Windows platform function from_ftime could return incorrect time if
the FILETIME that is being passed to the function contained dates before 1970-Jan-01.

Bug fix

Fixed a possible crash in gregorian::special_value_from_string if the string
did not represent a valid special value.

Bug fix

Removed the testfrmwk.hpp file from the public include directory. This file
was internal for the library tests and was not documented.

Fixed dereferencing end string iterators in different places of code,
which could cause crashes on MSVC
(#2698).

Changes from Boost 1.33 to 1.34 (date_time 1.04 to 1.05)

Type

Description

Feature

Updated the data in the date_time_zonespec.csv file to reflect new US/Canada
daylight savings time rules for 2007. If you upgrade to the new file, be aware
that the library will only give correct answers for current/future date
conversions. So if you are converting dates from earlier years the answers
will reflect current time zone rules not past rules. The library doesn't support
historic timezone rules presently.

Feature

Two other dst calculation features have also been update to reflect the new
US/Canada timzone rules. This is the boost::date_time::us_dst_rules and
dst_calc_engine. While the us_dst_rules is officially deprecated, a patch
by Graham Bennett has been applied which allows this class to work correctly
for both historical and future dates. The dst_calc_engine was updated to also
work for historical and future times. This allows the various local_adjustor
classes to work correctly. There was an interface change for classes using the
dst_calc_engine with custom dst traits classes. The traits classes signatures
changed to take a 'year' parameter on most of the methods such as end_month.
In addition, 2 new functions are needed on the traits classes:
static date_type local_dst_start_day(year_type year) and
static date_type local_dst_end_day(year_type year).
Implementers should see date_time/local_timezone_defs.hpp for
examples.

Bug Fix

Fix DST traits for Austrialia (sf# 1672139) to set end of DST at 3:00 am instead of 2:00 am.

Bug Fix

Fix a problem with potential linking error with multiple definitions due
to I/O code.

Bug Fix

Changed serialization code in both greg_serialize.hpp and time_serialize.hpp
to eliminate warnings due to unused variables for version and file_version.
Thanks to Caleb Epstein for the patch suggestion.

Bug Fix

Fix regression errors that showed up under FreeBSD with GCC and the
LANG environment set to russian -- changed parser to use classic
locale instead of blank locale.

Bug Fix

Changes for tracker issue 1178092 -- change in convert_to_lower to make
local a const static and speed up parsing.

Bug Fix

Patches from Ulrich Eckhardt to fix support for EVC++ 4.

Feature

Reduce the usage of basic_stringstream as much a possible to work around
a bug in the VC8 standard library. See
mailing list archive
for more information.

Changes from Boost 1.32 to 1.33 (date_time 1.03 to 1.04)

Type

Description

Bug Fix

Period lengths, when beginning and end points are the same, or are consecutive, were being incorrectly calculated. The corrected behavior, where end and beginning points are equal, or a period is created with a zero duration, now return a length of zero. A period where beginning and end points are consecutive will return a length of one.

Bug Fix

Time_input_facet was missing functions to set iso formats. It also failed to parse time values that did not use a separator (%H%M%S). Both these bugs have been corrected.

Feature

Preliminary names of ptime_facet and ptime_input_facet changed to simply time_facet and time_input_facet. The ptime_* versions have been removed all together.

Feature

The from_iso_string function failed to parse fractional digits. We added code that correctly parses when input has more digits, or too few digits, that the compiled library precision. Ptimes with only a decimal are also correctly parsed.

Bug Fix

The parsing mechanism in the new IO would consume the next character after a match was made. This bug presented itself when attempting to parse a period that had special value for it's beginning point.

Bug Fix

The new IO system failed to provide the ability for the user to "turn on" exceptions on the stream. The failbit was also not set when parsing failed. Both of these problems have been fixed.

Bug Fix

Parsing of special values, by means of from_*_string functions, has been fixed. This also effects the libraries ability to serialize special values. Time_duration now serializes as either a string or individual fields (depending on is_special()).

Bug Fix

Previously, output streaming of partial_date would display the day as either a single or double digit integer (ie '1', or '12'). This has been corrected to always display a double digit integer (ie '01').

Feature

Major new features related to management of local times.
This includes the introduction of a series of new classes to
represent time zones and local times (see Date Time Local Time for complete details).

Feature

Input and output facets have been re-written to support format-based
redefinition of formats (see Date Time IO for complete details).

Feature

Functions have been added to facilitate conversions between tm structs for date, ptime, time_duration, and local_date_time. Functions for converting FILETIME, and time_t to ptime are also provided. See the individual sections for details.

Feature

A universal_time function has been added to the microsec_time_clock (full details of this function can be found here).

Feature

Functions have been added to facilitate conversions between tm structs for date, ptime, time_duration, and local_date_time. Functions for converting FILETIME, and time_t to ptime are also provided. See the individual sections for details.

Feature

A universal_time function has been added to the microsec_time_clock (full details of this function can be found here).

Feature

Date-time now uses reentrant POSIX functions on those platforms that
support them when BOOST_HAS_THREADS is defined.

Bug Fix

Fixed a bug in serialization code where special values
(not-a-date-time, infinities, etc) for
ptime, time_duration would not read back correctly from an archive.
The output serialization code wrote subfields such
as time_duration.seconds() which are invalid for special values and
thus undefined values. Thus when read back the values could cause
strange behavior including execeptions on construction.

Bug Fix

Fixed multiple warnings generated with various platforms/compilers.

Bug Fix

Construction of a ptime with a time_duration beyond the range of 00:00 to 23:59:59.9... now adjusts the date and time to make the time_duration fall within this range (ie ptime(date(2005,2,1), hours(-5)) -> "2005-Jan-31 19:00:00" & ptime(date(2005,2,1), hours(35)) -> "2005-Feb-02 11:00:00").

Bug Fix

Time parsing now correctly handles excessive digits for fractional seconds. Leading zeros are dropped ("000100" -> 100 frac_sec), and excessive digits are truncated at the proper place ("123456789876" -> 123456 or 123456789 depending on what precision the library was compiled with).

Bug Fix

Changes to the boost::serialization interface broke serialization compatibility for date_time. The user must provide a function to insure date_time objects are const before they are serialized. The function should be similar to:

Use of the depricated boost::tokenizer interface has been updated to the current interface. This fixes compiler errors on some older compilers.

Bug Fix

Templatized formatters in the legacy IO system to accept char type. Also removed calls to boost::lexical_cast.

Changes from Boost 1.31 to 1.32 (date_time 1.02 to 1.03)

Type

Description

Bug Fix

Snap to end of month behavior corrected for year_functor. Previously, starting
from 2000-Feb-28 (leap year and not end of month) and iterating through the next
leap year would result in 2004-Feb-29 instead of 2004-Feb-28. This behavior has
been corrected to produce the correct result of 2004-Feb-28. Thanks to Bart Garst
for this change.

Feature

Free function for creating a ptime object from a FILETIME struct. This function
is only available on platforms that define BOOST_HAS_FTIME.

Feature

Microsecond time clock is now available on most windows compilers as well as
Unix.

Feature

Use of the boost::serialization library is now available with most of the
date_time classes. Classes capable of serialization are: date_generator classes,
date, days, date_period, greg_month, greg_weekday, greg_day, ptime, time_duration,
and time_period. Thanks to Bart Garst for this change.

Feature

Functions added to convert date and time classes to wstring. The library now
provides to_*_wstring as well as to_*_string functions for: simple, iso,
iso_extended, and sql for dates and compilers that support wstrings. Thanks to
Bart Garst for this change.

Feature

Period classes now handle zero length and NULL periods correctly. A NULL period
is a period with a negative length. Thanks to Frank Wolf and Bart Garst for this
change.

Feature

Added end_of_month function to gregorian::date to return the last day of
the current month represented by the date. Result is undefined for
not_a_date_time or infinities.

Bug Fix

Removed incorrect usage of BOOST_NO_CWCHAR macro throughout library.

Feature

New names added for some date classes. Original names are still valid but may
some day be deprecated. Changes are:

New experimental duration types added for months, years, and weeks. These classes
also provide mathematical operators for use with date and time classes. Be aware
that adding of months or years a time or date past the 28th of a month may show
non-normal mathematical properties. This is a result of 'end-of-month'
snapping used in the calculation. The last example below illustrates the
issue.

Added constructors for date and ptime that allow for default construction (both)
and special values construction (ptime, both now support this). Default
constructors initialize the objects to not_a_date_time (NADT).

Fixed bug in duration_from_string() where a string formatted with
less than full amount of fractional digits created an incorrect
time_duration. With microsecond resolution for time durations
the string "1:01:01.010" created a time duration of
01:01:01.000010 instead of 01:01:01.010000

Bug Fix

Fixed the special value constructor for gregorian::date and posix_time::ptime
when constructing with min_date_time or max_date_time. The wrong value was
constructed for these.

Changes from Boost 1.30 to 1.31 (date_time 1.01 to 1.02)

Type

Description

Bug Fix

Build configuration updated so dll, statically, and dynamically linkable library files are now produced with MSVC compilers. See Build/Compiler Information for more details.

Fixed time_duration_traits calculation bug which was causing time duration to be limited to 32bit range even when 64 bits were available. Thanks to Joe de Guzman for tracking this down.

Bug Fix

Provided additional operators for duration types (eg: date_duration, time_duration). This includes dividable by integer and fixes to allow +=, -= operators. Thanks to Bart Garst for writing this code. Also, the documentation of Calculations has been improved.

Added a function to time_duration to get the total number of seconds in a
duration truncating any fractional seconds. In addition, other resolutions
were added to allow for easy conversions. For example

Added unary- operators for durations for reversing the sign of a time duration. For example:

time_duration td(5,0,0); //5 hours
td = -td; //-5 hours

Thanks to Bart Garst for this work.

Feature

Added support for parsing strings with 'month names'. Thus creating a date object from string now accepts multiple formats ("2003-10-31","2003-Oct-31", and "2003-October-31"). Thus, date d = from_simple_string("2003-Feb-27") is now allowed. A bad month name string ( from_simple_string("2003-SomeBogusMonthName-27")) will cause a bad_month exception. On most compilers the string compare is case insensitive. Thanks to Bart Garst for this work.

Feature

In addition to support for month names or numbers, functions have been added to create date objects from multi-ordered date strings. Ex: "January-21-2002", "2002-Jan-21", and "21-Jan-2003". See Date Class for more details.

Bug-Fix

Various documentation fixes. Thanks to Bart Garst for updates.

Changes from Boost 1.29 to 1.30 (date_time 1.00 to 1.01)

Notice: The interface to the partial_date class (see date_algorithms) was changed. The order of construction parameters was changed which will cause some code to fail execution. This change was made to facilitate more generic local time adjustment code. Thus instead of specifying partial_date pd(Dec,25) the code needs to be changed to partial_date pd(25, Dec);

Type

Description

Bug Fix

Added new experimental feature for Daylight Savings Time calculations. This allows traits based specification of dst rules.

Feature

Added new interfaces to calculate julian day and modified julian day to the gregorian date class. See boost::gregorian::date.

Added a length function to the period template so that both date_periods and time_periods will now support this function.

Bug Fix

Split Jamfiles so that libs/date_time/build/Jamfile only builds library and /libs/date_time/libs/test/Jamfile which runs tests.

Bug Fix

Fixed many minor documentation issues.

Bug Fix

Removed the DATE_TIME_INLINE macro which was causing link errors. This macro is no longer needed in projects using the library.

Bug Fix

Added missing typedef for year_iterator to gregorian_types.hpp

Bug Fix

Fixed problem with gregorian ostream operators that prevented the use of wide streams.

Bug-Fix

Tighten error handling for dates so that date(2002, 2, 29) will throw a bad_day_of_month exception. Previously the date would be incorrectly constructed. Reported by sourceforge bug: 628054 among others.

Acknowledgements

Many people have contributed to the development of this library. In particular Hugo Duncan and Joel de Guzman for help with porting to various compilers. For initial development of concepts and design Corwin Joy and Michael Kenniston deserve special thanks. Also extra thanks to Michael for writing up the theory and tradeoffs part of the documentation. Dave Zumbro for initial inspiration and sage thoughts. Many thanks to boost reviewers and users including: William Seymour, Kjell Elster, Beman Dawes, Gary Powell, Andrew Maclean, William Kempf, Peter Dimov, Chris Little, David Moore, Darin Adler, Gennadiy Rozental, Joachim Achtzehnter, Paul Bristow, Jan Langer, Mark Rodgers, Glen Knowles, Matthew Denman, and George Heintzelman.