Support for Time Zones of users in Mahara

[Peter Barlow]

Did a quick search here and couldn't easily find an existing request for timezone support.
Unlike this eduforge tracker when I created my account, where I was prompted to confirm my time zone, there seems to be no such Time Zone support within the Mahara system and therefore I have to mentally adjust time stamps against forum, blog, and other posts.
Hope this request can find its way into your todo list soon.
Cheers, Peter B.

There is a specification for this:

  https://wiki.mahara.org/index.php/Developer_Area/Specifications_in_Development/timezones

[Nigel-catalyst (nigel-catalyst)]

Indeed, there is no timezone offset feature in Mahara right now.

[Ray Merrill (rmerrill)]

Although a long term fix needs to allow calendar artefacts
(specifically reminders which get triggered by cron) to
reflect local times for each user, this short term patch
will let you adjust the server timezone to reflect a single
timezone for the majority of your users.

* IMPORTANT * Only works for PHP version 5.1 or higher.

------- ADD THE FOLLOWING TO YOUR CONFIG.PHP FILE --------

// which timezone the server should be acting on - must be
from the list of supported timezones
// ... see http://www.php.net/manual/en/timezones.php
// IMPORTANT: only works if your server is using PHP
version 5.1 or greater
$cfg->servertimezone = 'America/New_York';
//$cfg->servertimezone = 'Pacific/Auckland';
//$cfg->servertimezone = 'Europe/London';
//$cfg->servertimezone = 'Asia/Tokyo';

--------- ADD THE FOLLOWING TO INIT.PHP AT AROUND LINE 62 -
AFTER config.php and config-default.php are processed ------

// fix server timezone, if needed (only works for PHP v5.1
or higher)
if (function_exists("date_default_timezone_set") and
function_exists("date_default_timezone_get")) {
    $CFG->defaultservertimezone = date_default_timezone_get();
    $CFG->originalservertimezone = $CFG->defaultservertimezone;
    if (isset($CFG->servertimezone)) {
        try {
            date_default_timezone_set($CFG->servertimezone);
            $CFG->currentservertimezone =
date_default_timezone_get();
        } catch (Exception $e) {
      if ($e instanceof ConfigSanityException) {
          throw $e;
      }
      $errormessage = ob_get_contents();
      if (!$errormessage) {
          $errormessage = $e->getMessage();
      }
      ob_end_clean();
      $errormessage = get_string('servertimezonefailed',
'error') . $errormessage;
      throw new ConfigSanityException($errormessage);
        }
    } else {
        $CFG->currentservertimezone =
date_default_timezone_get();
    }
}

[Nigel-catalyst (nigel-catalyst)]

Ray - the minimum required version of PHP for Mahara is 5.1.3, so your checks could be removed :)

[Andrew Nicols (dobedobedoh)]

The suggested fix for this is actually buggy.
The time is entered into the database correctly, but is also applied when reading the row back.

[Ruslan Kabalin (rkabalin)]

The solution could be setting GMT offset for server location in Site settings, as well as local GMT offset for individual user. Based on this all time stamps presented to user (as well as submitted by user) will be shifted in time according to zones difference so that only local time of the server will be used in the database time-related fields.

[Darryl Hamilton (lordp)]

I'm not sure if this is the right way to handle this, or if it will work in Mahara, but in a Ruby on Rails site that uses time zones, all date/time information is stored in the database in UTC.

Conversion to a user's timezone is done before it is displayed, and all dates entered by a user are assumed to be in their time zone, and are converted to UTC before storing in the database.

For anonymous/public access, perhaps a site default can be used?

[François Marier (fmarier)]

Darryl: that's also the way that Moodle does it. I think it makes sense. (users can choose their timezone in their user profile area)

[Kristina Hoeppner (kris-hoeppner)]

We keep this on the list for Mahara 1.7; may require some assistance from a DB expert.

[Jiri Baum (Catalyst) (jiri-catalyst)]

In addition, time zones should be handled as zones (rather than a numeric offset) so that historical and future datetimes are shown correctly (for instance, those before/after daylight saving switch).

Bare dates such as "date of birth" should be stored as dates, not as datetimes; the current technique of adding 3600s to a datetime in order to get a date is somewhat problematic.

[Aaron Wells (u-aaronw)]

This would still be great to have, but it'll be quite an undertaking. As others have mentioned, the most common way of doing this is to store the dates in UTC in the database, and then before displaying it to the user, converting it to that user's chosen timezone.

The annoying thing is that we'll need to track down every place in the code that a date is displayed to the user and do this conversion. A lot of these will have been passed through format_date(), so putting a conversion in there will cover all of those, but there are sure to be quite a few where format_date() was bypassed.

We'll also need a one-time script to convert all the stored dates in the database from their current time to UTC.

[Robert Lyon (robertl-9)]

I feel the fix in https://bugs.launchpad.net/mahara/+bug/1771362 will be sufficient for this - where we sync how we deal with dates/times in both PHP and the database level