Re: [Boost-users] [date_time] timezone rules for different years
-----Original Message----- From: Stephen Turner [mailto:sturner@clicktracks.com] Sent: 22 December 2006 16:39 To: 'boost-users@lists.boost.org' Subject: [date_time] timezone rules for different years
For my application, I need to be able to get the local time of any UTC time in the last five years in any location.
As far as I can see, the date_time library doesn't provide this. The documentation says that date_time_zonespec.csv is "based on data found in the zoneinfo datebase", but whereas the zoneinfo database contains historical information about daylight saving time changes, date_time_zonespec.csv only seems to allow you to specify a single rule for each timezone. And I can't find another mechanism to do it.
Am I missing something, or is this capability not present? And if not, is there any plan to add it? Or a workaround? I anticipate that this will become more of a problem when the rules for the U.S. change by several weeks next year.
I'm not sure whether this one got lost in the holiday break, or whether there's nobody who's familiar with the internals of this library on this list, but let me try again. I've been trying to work out how to add the capability to have different timezone rules in different years to the library. It seems to me it's not too hard (although I'm nervous of making such a judgement in code I'm not familiar with). I think all that's needed is: 1) In class custom_time_zone, the rules should depend on y, rather than there just being one set of rules. 2) The date_time_zonespec.csv file would have to have extra columns for years a rule applied to. tz_db_base::parse_string would have to parse them, and instead of creating a new timezone for each line, add the rule to the appropriate timezone if it had already been seen once. Is there anything else that would need to be done? Actually, I think the hardest part would be populating the date_time_zonespec.csv file. Is there already a program to generate that file from the zoneinfo files, or was it done semi-by-hand? Thanks, -- Stephen Turner, Cambridge, UK http://homepage.ntlworld.com/adelie/stephen/ "The internet is a reflection of our society. If we do not like what we see, the problem is not to fix the mirror, we have to fix society." (Vint Cerf)
Stephen Turner wrote:
-----Original Message----- From: Stephen Turner [mailto:sturner@clicktracks.com] Sent: 22 December 2006 16:39 To: 'boost-users@lists.boost.org' Subject: [date_time] timezone rules for different years
For my application, I need to be able to get the local time of any UTC time in the last five years in any location.
As far as I can see, the date_time library doesn't provide this. The documentation says that date_time_zonespec.csv is "based on data found in the zoneinfo datebase", but whereas the zoneinfo database contains historical information about daylight saving time changes, date_time_zonespec.csv only seems to allow you to specify a single rule for each timezone. And I can't find another mechanism to do it.
Am I missing something, or is this capability not present? And if not, is there any plan to add it? Or a workaround? I anticipate that this will become more of a problem when the rules for the U.S. change by several weeks next year.
I'm not sure whether this one got lost in the holiday break, or whether there's nobody who's familiar with the internals of this library on this list, but let me try again.
Hi Stephen - Yes, sorry I was off the net on holiday for an extended period :-) Finally getting caught up now...
I've been trying to work out how to add the capability to have different timezone rules in different years to the library. It seems to me it's not too hard (although I'm nervous of making such a judgement in code I'm not familiar with). I think all that's needed is:
1) In class custom_time_zone, the rules should depend on y, rather than there just being one set of rules.
Since the core of the library uses time_zone as an abstraction, the intent would be to derive from this class and implement one that implements the multi-year timezone rules. The methods time_type dst_local_start_time(year_type); time_type dst_local_end_time(year_type); are the key. The returned values for these methods would be varied by the year. Note that you can also derive from the custom_time_zone class and just re-implement these two methods if you so desire. Of course that doesn't help with the tz_database as you discuss below.
2) The date_time_zonespec.csv file would have to have extra columns for years a rule applied to. tz_db_base::parse_string would have to parse them, and instead of creating a new timezone for each line, add the rule to the appropriate timezone if it had already been seen once.
Is there anything else that would need to be done?
I would recommend that this be created as an alternative tz_database class -- something like 'historic timezone database'. My experience is that must applications don't need the historic data and hence only really care about loading up the current set of rules. I can see that the library form is not optimum for this as you'd like to reuse most of the current code with slight modifications. We can work on that.
Actually, I think the hardest part would be populating the date_time_zonespec.csv file. Is there already a program to generate that file from the zoneinfo files, or was it done semi-by-hand?
There was a script somewhere (don't know if I still have it), but it was semi-by-hand. As you mentioned in another mail you could have a new tz database that could read the tzdb files directly. Personally, I don't have a use for this or time to implement it myself, but if you are motivated I'm willing to help you through the process and add into the library when it is complete. Jeff
Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
Yes, sorry I was off the net on holiday for an extended period Finally getting caught up now...
I've been trying to work out how to add the capability to have different timezone rules in different years to the library. It seems to me it's not too hard (although I'm nervous of making such a judgement in code I'm not familiar with). I think all that's needed is:
1) In class custom_time_zone, the rules should depend on y, rather than there just being one set of rules.
Since the core of the library uses time_zone as an abstraction, the intent would be to derive from this class and implement one that implements the multi-year timezone rules. The methods
time_type dst_local_start_time(year_type); time_type dst_local_end_time(year_type);
are the key. The returned values for these methods would be varied by the year. Note that you can also derive from the custom_time_zone class and just re-implement these two methods if you so desire.
Of course that doesn't help with the tz_database as you discuss below.
2) The date_time_zonespec.csv file would have to have extra columns for years a rule applied to. tz_db_base::parse_string would have to parse them, and instead of creating a new timezone for each line, add the rule to the appropriate timezone if it had already been seen once.
Is there anything else that would need to be done?
I would recommend that this be created as an alternative tz_database class -- something like 'historic timezone database'. My experience is that must applications don't need the historic data and hence only really care about loading up the current set of rules. I can see that the library form is not optimum for this as you'd like to reuse most of the current code with slight modifications. We can work on that.
Actually, I think the hardest part would be populating the date_time_zonespec.csv file. Is there already a program to generate that file from the zoneinfo files, or was it done semi-by-hand?
There was a script somewhere (don't know if I still have it), but it was semi-by-hand. As you mentioned in another mail you could have a new tz database that could read the tzdb files directly. Personally, I don't have a use for this or time to implement it myself, but if you are motivated I'm willing to help you through the process and add into the library when it is complete.
Jeff
I'm wondering if any actual effort is being put into this or if it has died off? I have some tools that use the boost::date_time libraries. The upcoming DST change from April to March made me realize that I am not accounting for historical changes to DST. It seems to me that even though most programs don't care about the historical data going back to 1918, they probably do care about the historical changes between 2006/2007. Any program that references a time in Mar. 2006 is going to be wrong if it assumes that new 2007 rules have been in effect forever. Rather than trying to develop a new file format that includes historical rules, is there any reason why we can't simply use the zoneinfo database already on most POSIX systems? I need to look more closely at the code to see how all of this works, but my first thought was, "Can I just change boost to point at /usr/share/zoneinfo instead of the zonespec.csv file?" -Matt
participants (3)
-
Jeff Garland -
Matt K -
Stephen Turner