Re: [Boost-users] [date-time] posix timezone string

From: Stering Wolfram (wolfram.stering_at_[hidden])
Date: 2005-11-04 03:14:38

[I am receiving this list in digested form, so this reply might not be 
correctly "linked" to its parent, I am afraid.]

On Thu, 03 Nov 2005 13:25:07 +0100, Stering Wolfram wrote

 >> I am implementing a year_based_date-derived date generator to
 >> calculate the easter sunday for a given year.  Now, this is the easy
 >> part, and it is done already.

 > Great!

 >> But I wonder how to generate a meaningful posix timezone string that
 >> is expected to result from calling the generator's to_string() member.
 >>
 >> The documentation at the (not well formatted, b.t.w.) "Description"
 >> section of class posix_time_zone didn't give any hints for Easter
 >> Sunday either.
 >>
 >> Any ideas?

 > I'm afraid I need a bit more context -- are you trying to generate a
 > local_time?  In general I wouldn't think you would care about local_time for
 > Easter?  Perhaps a bit of code to show what you want to do?

No local_time, just a boost::gregorian::date should be generated, like 
partial_date for example.

So, here we go:
What I want to achieve is something like the following:

- -----------------------------------------------
// Use the Gauß Formula
easter_sunday<date, GregorianEasterSundayGauss> es_gauss;

// Use Oudin's Formula
easter_sunday<date, GregorianEasterSundayOudin> es_oudin;

partial_date pd( 16, Apr );

date d1 = es_gauss.get_date( 2006 );	// 2006-Apr-16
date d2 = es_oudin.get_date( 2006 );	// 2006-Apr-16
date d3 = pd.get_date( 2006 );		// 2006-Apr-16

assert( d1 == d2 );
assert( d1 == d3 );

// But, of course:
date d4 = es_gauss.get_date( 2007 );	// 2007-Apr-08
date d5 = pd.get_date( 2007 );		// 2007-Apr-16

assert( d4 != d5 );
- -----------------------------------------------

with easter_sunday<> being defined as follows, modeled after other year based 
generators (from date_generators.hpp) with the policy defining the algorithm 
used to actually calculate the easter sunday date for a given year, which 
differs for the gregorian calendar (catholic, protestants) and the julian 
calendar (orthodox).  The policy could be expected to provide an operator()( 
year ) which returns an easter_sunday::date_type, for example.

- -----------------------------------------------
template <typename date_type, typename policy>
easter_sunday : public year_based_generator<date_type>
{
   public:
     typedef date_type::calendar_type calendar_type;
     typedef date_type::year_type     year_type;

     easter_sunday() {}  // does not require any arguments.
     virtual ~easter_sunday() {}
     virtual date_type get_date( year_type y ) const
     { return _generator_alg( y ); }
     virtual std::string to_string() const
     { return "easter_sunday"; /* or what? */ }

   private:
        policy _generator_alg;
};
- -----------------------------------------------

One remaining glitch is the typedef, as exists for the other generators to 
pull in the name into the gregorian namespace (gregorian_types.hpp), which is 
not possible for the policy-based easter_sunday, as a partial template 
specialization typedef would be required...
It would be nice to just say easter_sunday<GregorianEasterSundayGauss> for 
example, being able to leave out the boost::gregorian::date.

A possible modification could be to change the (compile time) policy-based 
implementation to use a function pointer in the constructor to set the 
algorithm to be used (kind of Strategy pattern) at run time.

Ah, yes, my original question actually was the to_string() which, according 
to the documentation of year_based_generator, is expected to return a string 
for use in a POSIX time_zone string.

regards,

-wolfi

-- 
DI Wolfram Stering
(Entwicklung)
HALE electronic GmbH., Salzburg, Austria
   Tel: [phone]
   Fax: [phone]
Email: wolfram.stering_at_[hidden]