1

Topic: timezone granularity

Has anyone here had to deal with mission-critical timezone resolution issues using PHP?

The timezone range provided by punbb is adequate for messages posted in the forum, however, in the work I've done bringing seamless event calendaring to the forum I'm starting to consider a modification or bolt-on which would give the users the choice of using the environment timezones (/usr/share/zoneinfo).  Here's a link to a lab I've setup to explore this.

If anyone has had to explore this kind of endeavor I would really enjoy hearing from you.

2

Re: timezone granularity

I've rolled a database mod, and modifications to several templates which comprise a complete change-over from using the numeric locality system to using the zoneinfo libs through php. I'm going to try to test this over the weekend with an event facility/plugin I wrote and if it works I'll post it all on punres.

In writing this mod I have learned about the caching/semaphores punbb uses, and reduced the static page sizes by several kb.

The flipside of this mod would probably be a localization layer. For English and some European forums it wouldn't be an issue, beyond that I imagine spelling "Asia/Pyongyang" would look much different.

The nice thing about using the zoneinfo calls is that instead of just relying on relative GMT the user can actually select a written locality. I also modified the header.php to display their timezone next to the Last Visit, so it looks like:

Last visit: 2005-05-09 15:16:34 (US/Arizona)

Hope everyone has a nice weekend.

Re: timezone granularity

Nice work. Looking forward to seeing this in action.

What do you mean by "reduces the static page sizes by several kb"?

"Programming is like sex: one mistake and you have to support it for the rest of your life."

4 (edited by dchan 2005-05-17 22:07)

Re: timezone granularity

Rickard wrote:

Nice work. Looking forward to seeing this in action.

What do you mean by "reduces the static page sizes by several kb"?

Thank you for taking an interest.

I have created two files in the cache/ folder.
One is a simple array containing integer/timezone string tuples.
The other is the guts of the form used to select timezone in the profile.php, admin_options.php, etc...
Doing this saves having to make a 500 tuple query each time profile.php or any other template calling the timezone info.

Here's how I reduced the static page size in the profile.php and other timezone modifying templates:

<select name="form[timezone]">
<option value="<? echo $pun_user['timezone']; ?>" selected><? echo $pun_tzones[$pun_user['timezone']]; ?></option>
<? require "cache/pun_time_zone_options.php"; ?>
</select>

Over the course of several templates this reduces the static page size by about 4kb a form and eliminates what would be a 499 conditional if block when using the zoneinfo for each timezone selection form.

Nothing too dramatic.  :-)  I think the templates are pretty lean already.
I've had fun working with PunBB.

I'm almost done writing up the documentation where I'm using

"diff mytree/filename.php  sourcetree/filename.php"

to note the changes. The timezone mod works and I'm testing it against an event system which enticed me to write the timezone mod to begin with. I finished the initial testing on that last night but I'm still tormenting it to see what breaks.

Re: timezone granularity

Ah, OK. 500 tuples? I didn't think there existed that many timezones.

I would be careful about placing stuff in the cache folder unless you have code to automatically regenerate the cache in case it is missing. What is in the cache folder is considered volatile. For example, the upgrade scripts usually delete all .php scripts in the cache folder.

"Programming is like sex: one mistake and you have to support it for the rest of your life."

6

Re: timezone granularity

Rickard wrote:

Ah, OK. 500 tuples? I didn't think there existed that many timezones.

I would be careful about placing stuff in the cache folder unless you have code to automatically regenerate the cache in case it is missing. What is in the cache folder is considered volatile. For example, the upgrade scripts usually delete all .php scripts in the cache folder.

Please check out the drop-down list in the timelab link I posted. I'm pretty sure there are 500 entries.

I did a tree of the zoneinfo folder and used a bit of perl to create a flatfile I could push at postgresql to fill a table. I'm going to pare it down a little but that's how many references there are.

When I was mentioning semaphores I was trying to say that I am using the existing code and definitions for regenerating cache files as an example. So I have setup the same mechanisms which exist for files PunBB is caching. I try to learn from examples.

As usual life is performing some blocking interrupts on my completing things.
I'm learning all about PHP's array fetishes and how to properly play with multi-dimensional associative arrays.

Re: timezone granularity

Ah, of course. My mistake smile

"Programming is like sex: one mistake and you have to support it for the rest of your life."

8

Re: timezone granularity

Just probably bungled my way through the punres project deployment shuffle.
Still scratching my head over the "release" setup and category selections. hmm

Hopefully I haven't left too many oversights.

timezone_mod