General developer forum

Sorry for not replying earlier, but I seem to have my hands fuller than I 'd like to these days. After this depressing preamble, though, let's start sharing the good news:

All the internal code that deals with DST offsetting is now in HEAD!
(and the people rejoiced)

Now, what we need to do first and foremost is:

1. Make a good and correct import procedure.
2. Provide seamless transition from the legacy $USER->timezone system.

The import procedure is currently being done by admin/dst_update.php (this will probably get a rename before long). You can reach that through the administration UI, but right now it's barely working correctly.

What it does do, is:

• Kill all your mdl_timezone table entries
• Parse $CFG->$CFG->dataroot.'/temp/olson.txt'
• Insert all the records it parses into mdl_timezone
• Insert a bunch of generic "Unspecified location" records as well
• die()

The first order of the day here is to make sure that all data is being parsed correctly. I 'm saying this because I 'm having some problems with parsing, namely olson_parse_at() seems to have problems with the America/St_Johns, America/Goose_Bay (these two use the StJohns rule) and Asia/Karachi zones. It leaves the times NULL. Some help from Martin L would be wonderful here. Regarding this process, olson_parse_at() is the only thing that doesn't give me a warm fuzzy feeling inside.

Once this crude import procedure works 100% correctly, we can refine it to be more gentle and have a pretty interface.

Another important thing here is the code snippet that inserts the "unspecified location" timezones in the table:

$timezone = new stdClass;
$timezone->year = 1970;
for($i = -13; $i <= 13; $i += .5) {
    $timezone->gmtoff  = $i * HOURSECS;
    $timezone->name    = get_string('timezoneunspecifiedlocation').' / GMT';
    $timezone->sortkey = 'UNSPECIFIED_'.sprintf('%05d', 13 * HOURSECS + $timezone->gmtoff);
    if($i < 0) {
        $timezone->name .= $i;
    }
    else if($i > 0) {
        $timezone->name .= '+'.$i;
    }
    insert_record('timezone', $timezone);
}

I 'm meaning for this to go into /lib/db/mysql.php exactly as it stands, but it's not there yet because of one thing. You 'll notice that it's setting a "sortkey" field in there, which doesn't exist in the database. The reason for this is that in the end "name" alone is not enough. Sorting these "unspecified location" timezones by name is ultra-yucky, it suffices to say that + comes before - in an alpha sort (not to mention that +10 comes after +1 and before +2).

It therefore seems that since we 're going to have to somehow sort nicely in order to show that "select timezone" drop down in the user profile, there's need for an additional field. In my dev install this is "sortkey varchar(100)", and it's only used for sorting that one drop down menu (talk about waste for the sake of prettiness). Does anyone have a better idea?

The above is one of the two things that are holding the "migration procedure" up right now. The other one is this:

Moodle currently has a "Server's TZ" setting for timezones. We probably need to have one that's equivalent under the new system. It's not technically required, because the admin can always upgrade, go to the vars config, pick the correct GMT+-X timezone and that's it. However, since people might have set that to "Server's TZ" they would be in for a big time-shifting surprise if they fail to do that, and I wouldn't want to be Martin's Moodle Services in that situation.

The problem is that our current GMT offset field is called "gmtoff", and it holds the offsets in seconds. There is going to be one record among the thousands in that table that we have to somehow mark as "this one isn't using a real offset, it's a placeholder for the server's offset". One possible idea would be to use the special value "-1" for that case. Another idea would be to use "999999999". An even more sly idea would be to not have such a record, and hardwire Moodle's internals to recognize a special "Default/Server" timezonename and act accordingly. I 'm not sure which one would be better, or even if there's an even slicker solution I haven't thought of. Thoughts anyone?

Once this is also taken care of, we can write an upgrade snippet that enters these records into mdl_timezone, updates the "timezonename" field for each user, updates $CFG->timezonename, drops the "timezone" field from mdl_user and follow up with code that totally uses the new timezone system for calculations.

(Right now, the "new" timezone is only used for DST offsetting; the "old" timezone is still used to determine offset in relation to GMT).

That's probably enough rhetoric for one day... any input on the highlighted issues?

Jon

PS: There's enough code in HEAD right now to test the DST offsetting yourselves if you like.