RE: [boost] Date/Time formal review

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-16 13:46:29

Joachim Achtzehnter wrote:

>Note also that even for applications that deal with only a single local
>timezone a date/time library needs to be aware of the DST situation to
>calculate the duration between two time points correctly. Does GDTL handle
>this case?

Yes.  This is not a feature of the posix_time system.  This system is a completely 'non-adjusted'
system.  So using it to perform calculations of local times that adjust for DST will not work.  To
do this the user should calculate in UTC, and then convert to local as has been discussed in this
thread.  The library currently provides 2 different techniques for performing the conversions
UTC/local conversions.  One uses the Timezone settings of the machine via the C API.  As an example:

  using namespace boost::posix_time;
  using namespace boost::gregorian;

  //This local adjustor depends on the machine TZ settings-- highly dangerous!
  typedef gdtl::c_local_adjustor<ptime> local_adj;
  ptime t10(date(2002,Jan,1), hours(7));
  ptime t11 = local_adj::utc_to_local(t10);

The second one uses functions that can calculate an offset based on specified DST rules.  You can
see the example in the docs:

http://www.crystalclearsoftware.com/libraries/gdtl/user_docs/local__utc__conversion_8cpp-example.htm
l

>What I find a little strange, by the way, is how gregorian and posix
>modules are so strictly separated. I would have expected the library to
>model date/time as generic concepts and then support different
>representations that can be converted into each other. After all, a given

This is a matter of software dependency.  I see no reason why a gregorian date system should depend
on a time library of any kind.  You can delete the posix_time subdirectory the gregorian library
will stand by itself.

>time point can be represented (labeled) in many different ways (as a
>time_t, as a Gregorian UTC date/time, a Gregorian date/time local to some
>timezone, as a Julian date, as a MJD, more accurately either of the above
>can be based on UTC, atomic time, or ephemeris time).

Sure there are all sorts of internal representations that can be used.  All have different
advantages and properties that make them more or less suitable for a given purpose.  The problem is
if we pick TAI, for example, as the universal internal representation then all sorts complications
(leap seconds) and limitations (pre-history support) are added with no benefit for large number of
applications.

So one big goal of GDTL enable the rapid construction of different date/time systems.
Convertibility between systems is really responsibility of the authors of those systems.  For
example, a date/time system might decide to export multiple time representations if that is useful
for users.  Or perhaps simply provide constructors or conversion functions.  For example, I believe
that the gregorian system should support Julian conversions.  The only reason it doesn't yet is that
there are only 24 hours in a day ;-)  Anyway, I expect these conversions to be added as additional
date/time systems are added to the library.

>Just for reference, there is an interesting library at the NASA Web site
>for conversions between various date/time representations:
> http://ringside.arc.nasa.gov/www/toolkits/julian_13/aareadme.html
>
>This doesn't deal with local times, but converts Gregorian date/time into
>various kinds of Julian or MJD representations and back. It does even take
>into account leap seconds, by the way.

Thanks for that.  I added a link to the reference page.  Wish there was some licensing info b/c it
looks like there is some nice work there that could be used to expand the current range of the
current library....

Jeff