Forum OpenACS Development: Re: What's the best approach to update timezone rules?

2: Re: What's the best approach to update timezone rules? (response to 1)

Posted by Jim Lynch on 02/08/14 05:04 AM

Do you mean adding a time zone such that someone can pick it from a list?

There are a coupla things to look at... one, is how your operating system stores timezones, and two, I think there is an openacs package named ref-timezones

what you would need to do is start with one (maybe the openacs package first) and see how it works. Maybe you can find out why the timezone is not working properly.

Additionally, if you could give a moreorless complete example of the specific trouble you're observing with the timezone, that would be helpful; maybe even that information might enable -me- to help you in more specific ways.

3: Re: What's the best approach to update timezone rules? (response to 2)

Posted by Cesareo Garcia Rodicio on 02/08/14 11:43 AM

Hi Jim

Sorry about the poor explanation. No, I mean add a rule to a specific timezone so it works properly.

As I've seen I could do a "insert rule in timezone_rules" for a specific timezone (with a specific tz_id) but I'm wondering it there is a way more "automatic".

My problem is with Timezone 'America/Montevideo' (in my installation tz_id = 130) . I think timezone rules are not properlly installed (I think DST rule).

I've checked openacs/packages/ref-timezones/sql/common/timezone-rules.dat
and it seems to be that rules are right but it seems to be an openacs update. I think (but I'm not sure) that upgrade-timezones.ctl didn't run) and before do that I ask

This is what I see in my database:

------ America/Montevideo is tz_id 130 ----
select * from timezones where tz ~ 'Mont';

 tz_id |             tz              | gmt_offset
-------+-----------------------------+------------
   113 | America/Kentucky/Monticello | -050000
   129 | America/Monterrey           | -060000
   130 | America/Montevideo          | -030000
   131 | America/Montreal            | -050000
   132 | America/Montserrat          | -040000
------ Timezone Rule (showing 4 records) -----
select * from timezone_rules where tz_id = 130 order by local_start desc limit 4;

 tz_id | abbrev |       utc_start        |        utc_end         |      local_start       |       local_end        | gmt_offset | isdst_p
-------+--------+------------------------+------------------------+------------------------+------------------------+------------+---------
   130 | UYT    | 1993-02-28 04:00:00-03 | 2038-01-18 06:14:07-02 | 1993-02-27 14:00:00-02 | 2038-01-18 15:14:07-02 | -10800     | f
   130 | UYST   | 1992-10-18 05:00:00-02 | 1993-02-28 03:59:59-03 | 1992-10-18 03:00:00-02 | 1993-02-27 14:59:59-02 | -7200      | t
   130 | UYT    | 1992-03-01 04:00:00-03 | 1992-10-18 04:59:59-02 | 1992-02-29 14:00:00-02 | 1992-10-17 12:59:59-03 | -10800     | f
   130 | UYST   | 1991-10-27 06:00:00-02 | 1992-03-01 03:59:59-03 | 1991-10-27 03:00:00-02 | 1992-02-29 14:59:59-02 | -7200      | t

Thanks!
Cesáreo

4: Re: What's the best approach to update timezone rules? (response to 3)

Posted by Gustaf Neumann on 02/08/14 12:04 PM

Hi Cesáreo,

when the data in packages/ref-timezones/sql/common/ looks right, then see packages/ref-timezones/tcl/apm-callback-procs.tcl for how to update the database.

all the best
-gn

5: Re: What's the best approach to update timezone rules? (response to 4)

Posted by Cesareo Garcia Rodicio on 02/08/14 02:15 PM

Hi Gustaf,

Yeah, it seems to be an upgrade problem. I'll load into database openacs/packages/ref-timezones/sql/postgresql/upgrade/upgrade-timezones.ctl

So the best approach seems to be:
1. Check rules in packages/ref-timezones/sql/common/timezones-rules.dat
2. Upgrade (vía upgrade-timezones.ctl or via apm-callback-procs.tcl)

Thanks !
Cesáreo

6: Re: What's the best approach to update timezone rules? (response to 5)

Posted by Cesareo Garcia Rodicio on 03/07/14 08:16 PM

I've forgot to upgrade this.

I had to upgrade it manually. It seemed to be originally an upgrade problem in my setup.

I had to do a DROP .. CASCADE (in upgrade script packages/ref-timezones/sql/postgresql/ref-timezones-drop.sql
there is no CASCADE and I had errors with events package).

Thanks
Cesáreo