Moodle in English: How to go around testing DST

Hi all,

I 've just finished adding the DST support in Moodle. At least I think I have...

We should test this to see if it works as expected. So here is a preliminary test procedure I 've written down. Since I 'm already half asleep, I may have overlooked something and of course this would be far from a complete test. But it's a starting point. So please help with your comments or by performing the experiment (or a variation thereof).

Take a server with TZ set to GMT+8 (Perth), no DST.
Moodle is configured to use Server's timezone as default.
User A has his timezone set to server timezone, no DST (Martin).
User B has his timezone set to GMT, DST preset: UK (last Sunday of March, 1 am, until last Sunday of October, 2 am). It is important that this DST preset is created by user B, since the times of (de)activation (1 am/2am) are local time.
The server's date/time is in February, thus no DST for anyone.
User B creates an event on March 15, 00:00.
User A should see this as March 15, 08:00.
User B creates an event on April 15, 00:00 (that's in his DST period).
User A should STILL see this as April 15, 08:00.
The server's date/time is changed to be let's say April 1.
Both users should see no change in their perceived event times.
Repeat experiment in another server located in the UK which has DST enabled for itself. Results should be the same.

Jon

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Friday, 18 February 2005, 12:11 PM

Thanks, Jon - please can everyone who is using 1.5 dev test this very thoroughly ... it's tricky stuff and very important to get right (since it affects times displayed thoughout the server, obviously).

Average of ratings: -

Does DST influence getusermidnight() ?

by Jan Dierckx - Sunday, 20 February 2005, 5:19 PM

Sorry, I can't help you with testing; this is way over my head. I was just wondering if this new DST code influenced the usergetmidnight() function?
I used the function in the 1.4 version of the glossary_random block and it worked fine. When a teacher wants to rotate the content of the block every day, logical behaviour would be to change it at 00:00am every day and not at whatever hour the teacher last changed the settings for the block. That's what I used the usergetmidnight function for.
In 1.5dev this no longer works. I put up some tests and I got strange results.
In 1.4 getusermidnight(time()) always results in a number smaller than time()
At least in my 1.5dev installation: getusermidnight(time()) results in a number bigger than time().

Have I missed some setting in 1.5dev (It is just a test install so I wasn't that carefull providing country settings, I haven't discovered the DST setting yet)?

Average of ratings: -

Re: Does DST influence getusermidnight() ?

by John Papaioannou - Monday, 21 February 2005, 8:49 AM

I cannot replicate this; it works correctly for me. Can you try with the very latest and if the problem still exists give more information (server timezone, user's settings, etc)?

Average of ratings: -

Re: Does DST influence getusermidnight() ?

by John Papaioannou - Monday, 21 February 2005, 12:00 PM

Update: I have added an extra sanity check in usergetdate(), which may help us track down the bug you are experiencing. I think a date('O') call is giving us problems (why?). There was another bug a few days ago which seems to have caused by it.

Please tell us if you get a "date('O') returns 99!" (or something like that) error.

Jon

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Friday, 18 February 2005, 2:17 PM

Jon, I've seen this code in CVS, and I'm curious. We are running on linux, and, assuming our time and settings are ok, we aren't seeing any problems. Is this a workaround to an underlying DST problem somewhere in POSIX? Database time functions? What's the problem scenario?

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Friday, 18 February 2005, 2:27 PM

After rereading the test plan, if the server is correctly configured to GMT+TZ, POSIX guarantees exactly the behaviour you are describing. What platform are you using that you see problems in describing times in the past/present/future affected incorrectly by DST?

Or is it that our timestamps aren't in GMT in the database? I'm kinda lost here

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Friday, 18 February 2005, 3:24 PM

Moodle 1.4 works fine storing current times when the timezones are set correctly. Actual times in the database have always been (and will continue to be) always stored in absolute seconds since epoch (GMT).

Problem occur when people are working in different DST regimes, or storing times across the DST boundaries.

The simplest example is someone setting an assignment due date now, to be 5pm on Friday in June. Currently, if we just change our own timezone by an hour when the DST shift happens - then that chosen moment will be displayed as 4pm instead and start causing confusion. All past times (eg dates on forum postings, logs etc) will appear to shift by an hour too!

Relying on the operating system here (posix or otherwise) does not help, because each user may be in a different part of the world with different DST behaviour.

The new system is smart about past and future dates and whether they are in a DST-shifted period or not. We have a user setting for each person, shifting dates at storage time (into absolute GMT), and shifting them back on retrieval according to whatever DST regime the user is under. The end result should be very intuitive.

Does that clarify things a bit?

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Saturday, 19 February 2005, 5:12 AM

"Does that clarify things a bit?"

A bit, but I'm kind-of not convinced that we're tackling the right problem. Let me explain myself...

By calling mktime, gmttime and localtime at the right places, Moodle is doing the right thing. Granted, we can spot bugs in places where (mk|gmt|local)time are called incorrectly, but those are implementation bugs. The general strategy Moodle is using (relying on POSIX) is the right one.

We depend, unfortunately, on the OS being configured correctly and the timezone files distributed with your OS being up-to-date. With countries changing their DST periods often, timezone files are a bit of a problem, actually, and I suspect that this affects many Moodle users.

If this is the problem we are out to solve, I think we should provide good instructions on how to update your timezone files (in Linux, /usr/share/zoneinfo, Windows must have an equivalent but I cannot find documentation for it).

Solving DST/timezone problems at the app level is fraught with peril, and it's one of those things that the OS provides.

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Saturday, 19 February 2005, 5:26 AM

My post assumed we were using set_locale() and localtime. Instead we are using a very custom get_user_timezone() and I can't figure out where $USER->timezone comes from.

Why are we reinventing the old & complicated wheel of POSIX time functions? (There must be a good reason for it!

Ah, by the way, I found where Windows hides it's TZ info: http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=14966&DisplayTab=Article

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Saturday, 19 February 2005, 9:43 AM

$USER->timezone is set in your profile - otherwise how would moodle.org (running on GMT+8) know that you (as a user) are at GMT+12 and want to see all your times as local times? Even then, how can the moodle.org POSIX time functions know whether you are in New Zealand or Samoa or Fiji (which probably have different DST regimes)? And how can these same time functions know how to convert an event created by Jon in Guildford for April 12th at 10:00am into a time that makes sense to you?

We couldn't find reliable answers to these questions using only POSIX time functions - even the current use of setlocale() for the language of times causes enough problems (let alone relying on it to know about the current laws of individual states within countries!).

Hence the new wheel (which seems to be working quite well so far!)

Average of ratings: -

Re: How to go around testing DST

by Zbigniew Fiedorowicz - Saturday, 19 February 2005, 10:32 AM

How does this address the classical problem of somebody in Indiana connecting to moodle.org? It seems to me that the only way to solve this would be to have some standard HTTP protocol for a server to ask a client: what time do you think it is?

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Saturday, 19 February 2005, 6:39 PM

The current scheme covers this ... I'd provide DST options on this site for that area, and those people can choose it from the menu in their profile, just like any other DST preset. On the other hand, it looks like Indiana must be used to being confused about time!

I originally wanted there to be a way for users to create their own DST settings (a custom preset) but Jon's not implemented that yet ... This would allow people in unusual areas to sort it out themselves without bothering the admin. I would still like to see this as an option on top of the central presets, Jon ...

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Monday, 21 February 2005, 9:02 AM

(whips cracking) Yes, master! (tortured screams from the dungeon) Of course, master! wink

I 'm copying some of the meat of our discussion the other day here so that we can all talk about it:

The activation/deactivation time for presets becomes with reference to GMT.
Each preset field acquires two new columns: hash, which is an md5 of (concatenation of all important preset data except name here) and userid.
The hash serves as a value which can be easily compared against others, transmitted, and stored. This will allow admins to install presets from existing packages we presumably will provide without a mess being made if they have already created some of them (duplicates will be detected easily).
A userid of 0 means that this preset is available for use sitewide (i.e., has been created by the admin for this purpose). Userid == X != 0 means that this preset has been configured by user with id = X and it's his "personal" setting.
This will allow users to use DST without the admin having to define presets for everyone (poor Martin with moodle.org), and will also allow the admin to see that N different users have defined the exact same preset for their personal use (hashes will be the same). A good hint that said preset should be promoted to sitewide usage.

Average of ratings: -

Re: How to go around testing DST

by Gustav W Delius - Friday, 18 February 2005, 2:59 PM

Very confusing stuff indeed. I don't even understand your example. Surely in April, when user B has summer time and user A does not their time difference is no longer 8 hours. So user A should not see your example event at 8am.

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Friday, 18 February 2005, 9:48 PM

Yes, you are right there. Lack of sleep. wide eyes

That difference should be 7 hours, but still it should remain the same regardless of the "current time" as the server reports it.

Average of ratings: -

Re: How to go around testing DST

by Eloy Lafuente (stronk7) - Friday, 18 February 2005, 5:18 PM

Uhm,

but when user A writes something in Perth (no DST), I should see differences depending if user B in London is under in DST period or not, isn't it?

Or I'm confused or something is wrong in your experiment text or something is wrong in the implementation.

In practice, when Martin goes to sleep (

) it's 02:00 in Perth local time, it's 16:00 in London in non DST periods (8 hours from GMT to GMT+8), but it's 17:00 (7 hours from GMT DST to GMT+8) in UK DST periods (where DST = +1)

So, chage "goes to sleep" to "create an event" and voilà, time display must change for users at London depending of their DST.

And the same is exactly equal if the "creator of events" is in London, Martin will see different times if the event has been created addressed to March (no DST) or to May (DST).

You can see it here:

Perth-London non DST (March 15th)
Perth-London DST (May 15th)

Ciao

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Friday, 18 February 2005, 6:58 PM

Sorry, I'm not understanding what you're saying the problem is with Jon's example.

Which lines in what he wrote do you see problems with?

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Friday, 18 February 2005, 8:40 PM

If I create an event at 2am in February and April, then yes, the London user will see different times but I will see the same time. That is correct.

If a London user creates events at 17:00 in February and April, then they will see the same time showing up, but for me it will be at different times. Also correct.

The crucial thing is that the creator's DST needs to be applied at the time of saving the date, so we can work out the exact moment they really meant (in seconds since the epoch) free of any timezone rubbish. Then for each reader we need to reverse the process, using the reader's DST settings and timezone.

Jon's example is a little complex, probably.

Here's a generic test:

Create two users, A and B, with different timezones and different DST presets.
As user A, create two assignments, or calendar entries, or quizzes etc: one inside the DST period, one outside. View the entries and verify they appear as you set them.
As user B, view the two entries and check the values are different than user A sees, but correctly point to the simultaneous moments (Eloy's links above can provide a good way to check these).
Change the server time in and out of the DST period and make sure that the displayed times don't change from either user A's perspective, and user B's perspective.

Average of ratings: -

Re: How to go around testing DST

by Eloy Lafuente (stronk7) - Friday, 18 February 2005, 10:34 PM

Hi,

sorry by these "silly" discussion. I'm pretty sure that it's due to my really poor English but, about your previous points:

1.- Ok.
2.- Ok.
3.- See below

4.- Ok. Changing server time souldn't change users perception.

Now, about 3:

If user B view the two entries he will see them different, ok. But he will see one entry different from the other too, isn't it? If Jon creates an event to phone you from UK at 00:00 (non DST) you will see such event (and receive the call) at 08:00 (your time) but, if he creates the event inside DST you will see (and the phone will ring) at 7:00 (your time). Am I wrong? Is this the current behaviour?

If "yes" the discussion ends here, else I've forgotten something!

Ciao

EDITED: Oh, I've just seen latest Jon's post about the correct diference when UK user is under DST should be 7. It explains all my doubts, I think.

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Friday, 18 February 2005, 11:14 PM

Yes, I believe the answer to your question is "yes". wink

The problem is that this is all good in theory. Maybe we should organize a testing event over at test.moodle.com or something.

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Saturday, 19 February 2005, 9:37 AM

When the Beta is more stable I'll switch moodle.org over to it. That should provide some good testing.

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Friday, 18 February 2005, 9:03 PM

By the way, there is actually a problem in our switch from strftime to gmdate, Jon (messes up translations) - I'm switching that part back this evening.

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Saturday, 19 February 2005, 10:00 AM

By the way, Jon, we still need that method that we talked about once of importing a DST preset list (from a file or a URL such as http://moodle.org/download/all-dst-info.csv) which becomes necessary with the centrally-defined presets.

Does anyone else want to help create a list of DST data? I'll need a fairly comprehensive list for this site (as will many others with international sites). it basically needs to be a csv file (preferably converted automatically from some authoritative source) containing something like (Jon?):

standard unique readable name, offset in minutes, activation day, month, time, deactivation day, month, time

Average of ratings: -

Re: How to go around testing DST

by Eloy Lafuente (stronk7) - Saturday, 19 February 2005, 7:11 PM

And such

activation day, month, time, deactivation day, month, time

must be in which timezone? (server's one, user's one, GMT, UTC ...?)

Ciao

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Monday, 21 February 2005, 8:54 AM

Right now the date and time are the user's local time. But I think we must change this to GMT to achieve the following:

Having DST presets which function the same also look the same in the database.
Enabling the admin to define DST presets without needing to know the time zone difference between GMT and a particular country/region in some cases.

I 'll get to it as soon as I can think of a suitably simple and non-ambiguous interface.

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Sunday, 20 February 2005, 2:09 AM

The list of DST data is included in every linux distro, and pretty standardized. Is is sometimes out of date, but there's a seriously large community with a vested interest in getting it right and up to date. Perhaps we could have a parser for that?

(some time passes)

I've done some research on the timezone files. They are included in libc6 in most (all?) modern distros, but the binary packages contain the zoneinfo files in a binary format that I wouldn't want to reverse engineer. The source for libc6 seems to include those files in "source text" form, which is described here http://london.pm.org/pipermail/london.pm/Week-of-Mon-20021202/015549.html , and seems eminently parseable and really easy for humans to edit.

These files are normally read by the zic utility (try `man zic` for the format definition). I'm trying to get hold of one to upload a sample.

If we can use this format, we can join the general linux/unix-related effort to have up-to-date timezone files, and save a lot of effort.

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Sunday, 20 February 2005, 2:14 PM

Sunny Sunday in windy Wellington. After some sailing in high winds I come back home and disassemble Debian's libc6 source package, which is suspected of containing the files we want.

I've attached a sample file for southamerica (edit: attached now!). The most up-to-date copy of these TZ files is available from this URL: ftp://elsie.nci.nih.gov/pub/

Like Eloy, I think we should limit our reinvention and reuse as much as we can. And what we do reinvent, we should study from the FOSS implementations in existence.

One question for MD/Jon: all this TZ show is quite reliable under unixes, shouldn't we use POSIX under unixes, even if we add a compatibility layer under Win32?

It would carry the added benefit having a debug mode under unix where we use both methods, and compare the results. If the two methods don't match, we have a suspicious case to investigate.

More importantly, I think that set_locale/localtime are unreliable in non-NT Win32 platforms (Win95/Win98/WinME) which are definitely going out of fashion. NT3.51 and newer do have a reasonably useful POSIX layer.

Additionally, I did a bit of research on how .net/ASP programmers are supposed to get this done under modern Win32 platforms, and the answer is set_locale/localtime, so it can't be _that_ broken (I'd hope, I haven't used a non-unix system for several years now

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Monday, 21 February 2005, 9:20 AM

Gasp... that file doesn't look to me like something that I 'd write a parser for and then not need to triple-check the results. I don't understand what some of the fields do (LETTER/S?), or their format. mixed

Of course I agree that we should reuse, but it's not really rocket science to think what the minimum amount of information that fully and accurately supports all possible settings will be. It might be a good idea to discuss some things though, like:

I 'm allowing changes to be triggered every half hour. Is this too much?
I 'm allowing DST time shifts different than 60 minutes (in fact, arbitrary). Is this too much?
I 'm allowing time shifts in both directions (i.e., both turning the clock forward as happens everywhere(?) and turning it backwards. Maybe this is pointless?

The motto was to err on the safe side, but if the interface can be safely simplified then we should do that.

You mention using the POSIX implementation at least as a double-check helper. I presume this means:

set_locale(something);
mktime(our desired timestamp here);
set_locale(back to Moodle settings);

I can see several faults with this:

How do we know what "something" is? And how does this cover the Indiana case (4 different DST zones in the same state)? The locale doesn't even allow resolution between states in the US, or does it?
I don't think we should be messing around with stronger measures like putenv(), which a) doesn't work in safe mode, b) intuitively sounds like it could very well behave differently under different configurations of server OS / PHP running mode etc, c) might not be adequate at all in the end.
If you just want to do a mktime(), then OK. But what if you want to do a strftime()? You need to have the "foreign" locale active while calculating what day it is, but you need to have the "Moodle" locale active while fetching the strings for names of months etc. Unfortunately, as strftime() does both things in one go, you cannot do that.

Finally, I haven't come across a single piece of multi-user software that has these very demanding user timezone/dst handling requirements, much more one that actually satisfies them. How can a piece of software know that my local time difference with Martin changes during the year, but it doesn't change with Eloy?

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Monday, 21 February 2005, 9:46 AM

All web (and non-web) applications that report dates to the user and have calendaring/scheduling facilities have the same requirements as Moodle. (Or is it something else that you are talking about?)

I've always used them in the projects I work on (Midgard, TWIG, etc), and haven't had a single problem. Granted, I'm unix-based.

These are *exactly* the requirements that these POSIX calls meet. If it doesn't work reliably on older Win32... we need a wrapper that detects Win32 and activates the bozo filter (or, even better, your functions

How can it know? It should know:
- the server TZ setting
- the server time
- from server's time + TZ derives GMT
- the user's TZ setting.

Everything in the DB is stored in GMT, and the TZ info includes DST details. And yes, there can be as many TZ settings for a single country, state or province as you want to feed it.

So we need to add an extra setting for the user: TZ. That's all. We are already storing stuff in GMT in the database.

With regards to the file format, I see two alternatives:
- we save time and write a simpler parser, and then duplicate the massive effort of maintaining the TZ files up-to-date
- we spend more time and write the parser for those TZ file, and save a huge duplication effort

There are several parsers already written. I found at least one in C and one in Java. I suspect there's one in Perl, which would be the easiest to port. The format is well documented in 'man zic'.

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Monday, 21 February 2005, 11:16 AM

Everything in the DB is stored in GMT, and the TZ info includes DST details. And yes, there can be as many TZ settings for a single country, state or province as you want to feed it.

This is the thing, Martin. Moodle's TZ setting definitely did not include DST details, and this whole "implement DST" business was waaaay low in priority until one day I jumped on it and after a while MD became interested on seeing it finished. Also, the prevailing idea at the time was "there's no way we can have all the DST presets in the world inside Moodle; we 'll be operating on a create-your-own policy". What I 'm trying to say here is that the current state of affairs owes a bit to that background; if I had asked Martin "do you think we should replace the whole date/time system with another one that supports DST" he would have said "sure, in Moodle 1.6".

So yes, what you suggest would be feasible, it would be nice, but it means digging deeper into Moodle. I would prefer to have a simple drop down selector for timezone and DST like Windows has myself, but how possible is that to achieve in 1.5? There's no way I can do all of this in time by myself... wink

Average of ratings: -

Re: How to go around testing DST

by Zbigniew Fiedorowicz - Monday, 21 February 2005, 11:27 AM

I still am not clear as to how Moodle is supposed to get the user's TZ.

In the user profile settings, is there a gigantic list where users can specify which part of Indiana they are from?
Or do we stick with our current interface asking what the user's local time is? And then pop up a new page, if say the user responds GMT-5, asking the user: are you perchance from Indiana? If so, which part of Indiana?
Or do we ask the user to upload their OS TZ zone files to Moodle? And explain to the user where to find them?

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Monday, 21 February 2005, 12:31 PM

I would add (4) how does a Moodle with worldwide audience cope? Should MD and others in the same situation hand-input the timezones?

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Monday, 21 February 2005, 4:47 PM

See the new discussion in the general developer forum ...

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Monday, 21 February 2005, 12:05 PM

I can understand where you are coming from. But even for a good coder like you, using a well thought-out, widely used and understood library is way faster in the long run.

I am happy to lend a hand to rework what we have to make the most of POSIX if it's available, and to have an import for the Olson files. I'll port the Olson parser from Perl to PHP to load zonefiles into any format you want.

Interested?

Average of ratings: -

Re: How to go around testing DST

by Eloy Lafuente (stronk7) - Sunday, 20 February 2005, 9:02 AM

If I'm not wrong it would be relatively easy to read such timezone information in java (from 1.4 it maintains its own database).

You can see an example-info generated from java in:

http://www.unitek.ch/dst/dst.html

although the tz database included in each Unix distro is a good alternative. I found this information page too:

http://www.twinsun.com/tz/tz-link.htm

And there is an OpenSource tz java parser in:

http://joda-time.sourceforge.net/

Ciao

Average of ratings: -

Re: How to go around testing DST

by Eloy Lafuente (stronk7) - Sunday, 20 February 2005, 10:30 AM

Anyway, viewing my previous posted list, it seems that there are a lot of timezones that doesn't fit into Moodle's DST definition (only last and first days are supported now). What about such timezones? And about timezones with arbitrary changes every year? If we have to maintain every change the list will grow and grow...

It seems that, with a few rules, we can cover a lot (Europe, USA...) but the rest can be difficult. Perhaps it would be enough to process automatically (daily) the full list of timezones to get the next DST enable/disable (similar to the list posted above), make a checksum of the whole list and to allow Moodle's servers to be syncronished with that list (automatically, using cron or via some manual download/install procedure). If so, we'll need to difference between automatic and manually edited DST to mantain them over syncs.

Uhm, re-inventing the wheel uses to be hard, really!

Ciao

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Monday, 21 February 2005, 9:26 AM

Allowing people to say "the third Saturday" or "the 20th" of some month is supported by the code, there's just no GUI for it. I didn't want to clutter the GUI with too many useless choices, and hoped that someone would fill in the blanks here with respect to what we need to support! wink

Timezones with arbitrary changes, you mean arbitrary number of changes? Like having DST on for two or more separate periods each year? Ack... dead

Distinguishing between automatic and custom presets will be easy with the hash and userid fields proposed above, obviously automatics would all have userid = 0 with that system.

BTW, does everyone agree with adding those fields?

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Sunday, 20 February 2005, 2:49 PM

What about PEAR's Date_Timezone? Haven't read the code, but the docs promise a reinvention (wrapper) of the posix timezone wheel.

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Monday, 21 February 2005, 9:31 AM

First time I hear about that, but I can see some possible problems:

Remember we need to either replace all of Moodle's existing time handling with that (risky) or else integrate parts of it into Moodle (difficult and probably not worth it).
Personally I dislike relying on anything PEAR because of the well-known issues with packages overlapping, doing the same thing in different ways and general feeling of "instability" PEAR has (for me at least). Admittedly this argument does not hold water in a logical debate, but you can't dismiss it ouf of hand since many people agree on it.

The DST part of handling time turned out to be very simple and straightforward to use (just grep for "dst_offset_on" in moodlelib). Of course, the underlying code behind "dst_offset_on" turns a bit complicated for implementation reasons, but the general idea is very easy to see in retrospect (sigh).

Cheers!

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Monday, 21 February 2005, 10:01 AM

Jon -- all I am trying to point out is that we are reinventing a tricky wheel. One that every webapp uses. So it's bound to exist, and very polished form. At any rate, let's take one from a polished calendaring application that we know has been around for ages, if we don't want to use POSIX calls.

We _can_ write our own, no doubt, and with a talented guy like you doing it, it may take us shorter than it took others to get it right (it took the GNU project a long time to iron it out). But DST is one of those things that look simple but are full of nuance, corner cases and subtle implementation bugs.

What's the downside of using tried-and-true code? In the case of this PEAR class, it doesn't solve our problem -- it's just a facny wrapper around PHP functions.

Average of ratings: -

Re: How to go around testing DST

by John Papaioannou - Monday, 21 February 2005, 11:23 AM

No downside, and no objection at all from me! I 'm not saying we shouldn't use them because ours is better! I 'm just saying "why not stick with ours now that it exists?"

Again, I respectfully repeat that so far this has been decided by "policy reasons". Before this thread started (before the existing implementation was in CVS!), IMHO Martin probably wouldn't have been agreeable to earthshaking changes here. Now that the can of worms is open, maybe.

At any rate, I 'm not doing anything more until we come to a consensus regarding this.

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Monday, 21 February 2005, 10:17 AM

Some more research:

the file I've uploaded from libc6 is in a standard format for timezone files, referred to as the 'Olson database' format. Here's a PHP-GPL implementation that seems to have parsed the TZ files into a set of arrays (yuck):

http://www.psyon.org/projects/tzphp/

and here are related resources (including more links to current tz files):

http://www.twinsun.com/tz/tz-link.htm

Apparently Perl's DateTime::TimeZone includes a small script called parse_olson that will read the files. It should be easy to port it to PHP.

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Monday, 21 February 2005, 12:30 PM

I looked at this PEAR module some time ago, as possible code we could include inside Moodle/lib (not use from PEAR directly, because I don't want PEAR dependency). Anyhow, this module does not seem to use the operating system POSIX stuff ... it has its own array of data with entries like this:

'CST6CDT' => array(
'offset' => -21600000,
'longname' => "Central Standard Time",
'shortname' => 'CST',
'hasdst' => true,
'dstlongname' => "Central Daylight Time",
'dstshortname' => 'CDT' ),

...and no concept of start/end date. At the time this worried me because it didn't seem flexible enough (for Indiana, for example) so I dropped the idea.

I like the idea of maintaining our own database table because it's ultimately flexible. We just need to improve the ways of getting data into the system.

Average of ratings: -

Re: How to go around testing DST

by Martín Langhoff - Monday, 21 February 2005, 12:53 PM

I read the code briefly, and saw comments indicating it wasn't reliable on Windows, so I thought it was using the standard functions. Probably not as polished as we want.

If we are to use an external lib, the strategy is to copy it to Moodle/lib like AdoDB and other dependencies. Yep, +1 on that too.

Other than Win32 support, what problems with localtime() have you found? If we managed to get a localtime() wrapper working ok under Win32... would it be good enough?

I am happy to help porting the perl script that reads Olson files to put things in a Moodle-magic table. Is there a requirement for non-standard DST patterns for users in Vanauatu?

Average of ratings: -

Re: How to go around testing DST

by Martin Dougiamas - Monday, 21 February 2005, 12:36 PM

I'll start a new discussion in the general developer forum to discuss what we need to do.

Average of ratings: -