[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