[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 es_gauss;
// Use Oudin's Formula
easter_sunday 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
easter_sunday : public year_based_generator
{
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: +43 (662) 439011 550
Fax: +43 (662) 439011 9
Email: wolfram.stering@hale.at
