Re: [boost] date_time: second_clock and microsec_clock errors
I'll turn it around the other way. Most instances of microsecond_clock never care about the a time_zone to adjust the time. So there is no reason to drag in that dependency. But, in fact, the overloading I pointed out above:
template<class time_type> class microsecond_clock { ... template<class time_zone_type> static time_type local_time(shared_ptr<time_zone_type> tz_ptr);
enables the microsecond clock to use a time zone. When using a local_date_time type the timezone is required. So it's true, you'll get a compile error if you try to call the other overloadings with a local_date_time, but that's the intent.
"... practicality beats purity" It would be nice to have small comment within source code or reference to documentation that explains why this is intent and\or work around to the problem.
Jeff
Thanks for help Roman Yakovenko
On Mon, 28 Nov 2005 16:09:47 +0200, Peter Dimov wrote
template<class time_zone_type> static time_type local_time(shared_ptr<time_zone_type> tz_ptr);
Why is tz_ptr templated on time_zone_type? Isn't a specific base class required from time_zone_type?
local_date_time does have a polymorphic base for time zone so that at runtime you can use posix_time_zone, custom_time_zone, interchangeably. However, didn't seem necessary to depend on a specific time zone type or even a base class in this code -- hence the template. Jeff
On Mon, 28 Nov 2005 16:00:47 +0200, Roman Yakovenko wrote
I'll turn it around the other way. Most instances of microsecond_clock never care about the a time_zone to adjust the time. So there is no reason to drag in that dependency. But, in fact, the overloading I pointed out above:
template<class time_type> class microsecond_clock { ... template<class time_zone_type> static time_type local_time(shared_ptr<time_zone_type> tz_ptr);
enables the microsecond clock to use a time zone. When using a local_date_time type the timezone is required. So it's true, you'll get a compile error if you try to call the other overloadings with a local_date_time, but that's the intent.
"... practicality beats purity"
It would be nice to have small comment within source code or reference to documentation that explains why this is intent and\or work around to the problem.
I agree -- will add to the ever deeping todo list :-)
Jeff
Thanks for help
Sure, thx for the comments. local_date_time is a new addition and hasn't received much use yet, so I'm expecting there to be a few issues with the docs and possibly even a few features missing... Jeff
participants (3)
-
Jeff Garland -
Peter Dimov -
Roman Yakovenko