Time Management

Created by: Lester Caine, Last modification: 06 Dec 2008 (06:32 UTC)

Background

When originally developed, tikiwiki stored all times offset by the server timezone. This provides a quick and crude bodge around the lack of a proper timezone management structure in html and PHP. The problem is that the second you have clients outside of the timezone of the server this approach introduces a level of anarchy which there had been various attempts to unravel. The correct approach was to ALWAYS store times in the database as UTC based, simple Unix epochs. Much of the complexity in calendar was stripped away, but it left one major hole since only UTC times could be displayed properly. The timezone offset returned with the browser header simple does not work since it lacks the information on which timezone on is actually in.

User time options

To get around the limitations of html, we have added an option in the user profile to set their timezone, and this is the only way to correctly present UTC times for the whole of the year. For those of us who have the misfortune of living in a daylight saving area, simply using the browser offset results in half of the times being an hour out.

Handling Daylight Saving

The basis for adding daylight saving offsets had been added to users some time ago, but the work had never been completed. In order to complete the work we do need the DateTimeZone facilities provided in PHP5.1 ( although 5.2.x seems to be more stable in this area ). This provides a long list of timezones to select from, and once this has been selected for a user, any displays returned to them will show the correct local time. This offset will also be used when entering times, and subtracted so that the correct UTC time is stored in the database.
DateTime makes the conversions quite easy, but it's own format function uses the single letter format strings rather than the %x strings of strftime which bitweaver currently uses and which ADOdb requires.

PHP4 Support

Backporting this to PHP4 may be possible, but I've never used it so do not know how to handle that. All that is needed is a means of using the timezone database from PHP4, but unless someone has already done that work I can't see any real incentive to start now. A move to PHP5 only should probably happen sooner rather than later.

Anonymous Users

One problem that this does leave is a 'local' time for the guest account. For those of us who are in single timezones, simply setting this to that timezone solves the problem, but where world wide access is required as a guest, this is not acceptable. Simply displaying UTC time would provide accurate information, but it may be more 'user friendly' to provide a display offset by the browser tz setting. All that is then required is that the displayed times show that they have the wrong offset during a daylight saving period. I don't think this can be fixed until browsers actually return timezone information.

ToDo

  1. Now that the exact nature of the problem has been sorted and tamed, the existing code really needs a good tidy up. References to 'server time' can be removed, and the use of $gBitSystem->mServerTimestamp-> should be replaced with a $gBitUser->mLocalTime-> since this is actually what is being used.
  2. The code of BitDate could be tidied up quite a bit, but until DateTime as provided by PHP can handle the full range of dates, a switch to the built in library is not practical. A decision to switch to PHP5 only support would allow much of the code to be simplified, since DateTime will return many of the formats which we manually create such as rfc2822.
  3. getUTCFromDisplayDate needs sorting so that it accepts a return from a form without having to use gmmktime everywhere.
  4. The problem of translation needs to sorted out, and while many of us only use English, it would be nice if bit_date_format simply returned the correct language in addition to the correct timezone for the user.
  5. bitcommerce has a complete locale database which it would be nice to use to provide some more individual touches, such as once a user has set their country, only the timezones relevant to that country are displayed. I have cloned this data a couple of times now, and used with the nlpg package, and my UK postcode table, but I think it would be worth providing bit_locale and while making it a core package makes sense, simply having it available optionally should work. The flag icons would probably move to locale, and user country select would default to simply reading that, or use local to provide country and an additional zone information.