Boost logo

Boost Users :

From: Duncan Woods (woods_at_[hidden])
Date: 2004-08-19 04:06:57


Jeff,

Thanks for your reply. I'm afraid I will have to find another solution
short-term but look forward to helping try out some of the betas in the
future. C++ has been aching for a definitive date-time library - what
are the current leaders?

re: tz database, it would be helpful to support caching the db results
in memory to avoid accidental/lazy implementations going to disk each time.

Thanks,
Duncan

Jeff Garland wrote:

>On Wed, 18 Aug 2004 20:33:10 +0100, Duncan Woods wrote
>
>
>>Hello All,
>>
>>I'm new to Boost and interested in using it for timezone conversions
>>but I'm not finding it terribly clear. An example, which works fine,
>>uses something of the form:
>>
>>typedef boost::date_time::local_adjustor<ptime, -5, us_dst> us_eastern;
>>
>>
>
>Yes, this allows you to build static converters for a small number of time
>zones with well defined rules. If there isn't a rule set in the library that
>suits your application you would need to create one of your own. Since this
>is totally undocumented, I'll help you if you really want to go this way.
>
>
>
>>1. My problem is that I wish to use DST settings other than US and
>>found definitions such as eu_dst_trait in local_timezone_defs.hpp
>>but these seem unused and unusable. Would it require implementation
>>of dst_rules.hpp type classes? If so, Boost would not give much advantage.
>>
>>
>
>I agree date_time doesn't support local time adjustments well...yet.
>
>
>
>>2. I would also have liked to specify dst & timezone combinations at
>>run-time which dynamic_local_time_adjustor sounds like it might do -
>>but it appears to have no members.
>>
>>
>
>It has members. Look at the bottom of
>libs/date_time/test/posix_time/testlocal_adjustor.cpp. Note the comment:
> //still experimental
>
>
>
>>3. Will date_time use the 'tz database' in the future?
>>
>>
>
>The short answer is yes and I expect it before 1.33.
>
>The long answer is that in future releases there will be a generic time_zone
>class that encapsulates the glob of interfaces that the library needs to
>correctly handle a time zone. The abstraction will use subclassing to support
>different concrete time zone implementations. We have a working prototype now
>that uses Posix timezone strings to construct. So you can do something like:
>
> posix_time_zone arizona_tz("MST-07");
> posix_time_zone ny_tz("EST-05EDT,M4.1.0,M10.5.0");
>
>We are working on a variant that will use data from the TZ database so you can
>say something like
> boost::shared_ptr<time_zone_base> tz(tz_database.find("America/New York"));
>
>What we are NOT planning to do is supporting all the historic timezones of the
> timezone database -- doesn't seem like it's worth the complication. We also
>are not planning on reading the TZ database binary format directly (it's a
>directory with binary files for each timezone for those that don't know).
>Rather we are looking at condensing the contents (probably fron VCALENDAR
>form) down to a single csv file that can be read in by the application and can
>be modified as need be using text editors, excel, etc. So in your app it
>would look something like:
> tz_database db("zones.csv");
> boost::shared_ptr<time_zone_base> tz(db.find("America/New York"));
>
>Of course this comes with a new local_time class that can use time zones
>natively to adjust, do calculations, input/output, etc. So in particular, I
>expect to be able to write the following kind of code
> tz_database db("zones.csv");
> boost::shared_ptr<time_zone_base> tz(db.find("America/New York"));
> local_date_time ny_time = second_clock::local_time(tz);
> //2004-Aug-18 05:27:00 EDT
> std::cout << "The current time in New York is: " << ny_time << std::endl;
>
>HTH,
>
>Jeff
>
>_______________________________________________
>Boost-users mailing list
>Boost-users_at_[hidden]
>http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net