History of Time Management
Version 1 | Current version | |
---|---|---|
BackgroundWhen 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 optionsTo 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 SavingThe 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 SupportBackporting 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 UsersOne 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
| BackgroundWhen 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 optionsTo 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 SavingThe 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 SupportBackporting 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 UsersOne 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
|