Displaying times in local user's timezone (worldwide support)?

RT Users
1

Hi all

I’m in the process of implementing RT to replace a custom Eventum fork
with Pg support and a few hacks that we’re running.

Since we offer 24x7 support and a strong SLA, RT provides some very
useful features, especially with RT::Extension::SLA and Business::Hours
. However, I’m running into a surprising and unexpected problem with
time zones. At this point it’s a trial instance with low ticket volumes
and user counts, and RT’s paid support doesn’t really have a casual
entry-level option suitable for “we’re thinking of using RT, how would
you meet this requirement”. So I’m asking you for ideas.

It seems that RT displays times in the server time zone. It doesn’t seem
to have a field in the user data to set the user’s time zone, nor does
it respect the browser’s timezone, which is discoverable using
JavaScript like:

-new Date().getTimezoneOffset()/60;

(this’ll handle half- and quarter-hour timezones fine too).

I can add a CustomField for the user’s time zone and get them to set it,
and I can give it a default value of “autodetect” that uses some JS to
detect the browser time zone. Ugly, but viable for providing the client
timezone to RT. That’s only half the answer, though.

The problem is that as far as I can tell RT doesn’t differentiate
between server time and local client time. The user object has no time
zone attribute. RT doesn’t appear to have an internal field for “client
time offset” or do any conversion of server time to local time for
display. The only way I can see to control time display is to use a
scrip/overlay to set the Perl interpreter timezone for each FastCGI
instance. I’m really concerned about this hack, though; I strongly
suspect it’ll break RT::Extension::SLA and Business::Hours - plus times
should always be stored in the database in the server time zone, and I
don’t think this approach would permit that.

Am I missing something? How are other people who’re offering 24x7
world-wide support handling time zones? Just setting the server time to
UTC and showing UTC times across the app? This will work, but from a
usability perspective it sucks, especially since RT doesn’t annotate
displayed times with the timezone they’re in.

If I have to I’ll live with UTC times for now and look at how hard it’d
be to patch RT to support differentiating between client and server
time. I’m really hoping there’s a good answer to this that I’m just
totally missing, though.

Ideas/suggestions?

Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2

Am I missing something?

Yes, yes I am. Inevitably, as soon as I posted this message I noticed
that there’s a timezone field in the user table, though it isn’t exposed
in the UI and is defined as “varchar(50)” with no CHECK constraint, so
it’s not exactly clear what’s supposed to go in it.

perldoc RT::User says:

“Returns the current value of Timezone. (In the database, Timezone is
stored as varchar(50).)”

… which is totally uninformative.

I found a comment in Date.pm saying that:

    require Time::ParseDate;
    # the module supports only legacy timezones like PDT or EST...
    # so we parse date as GMT and later apply offset, this only
    # should be applied to absolute times, so compensate shift in NOW

suggesting that these timezones might be such legacy timezones. There’s
just one wee problem with that: Those timezone acronyms are not unique.
EST for example can mean USA Eastern States Time or Australian Eastern
States Time. They are also DST-unaware, since there’s a different TZ
acronym for DST timezones, eg EDT for USA Eastern Daylight Time. This is
why PostgreSQL has a config parameter used to decide which region
ambiguous offsets resolve to.

A look at the perldoc for Time::ParseDate suggests that it also
understands UTC offsets, which are at least unambiguous:

http://search.cpan.org/~muir/Time-modules-2003.0211/lib/Time/ParseDate.pm#Timezone_formats:

but no support for modern timezone specs like Australia/Perth that
auto-adjust to DST based on tzdata rules.

The apparent lack of use of the timezone field within RT makes me wonder
if it’s incomplete / non-working. I’ll test it out quickly, but it’s
hard to be confident in it when it’s not exposed by default. Anyone have
comments/experiences? I’m not a a big Perl user, so I’m not sure what
the support for modern dates, offsets and timezones is like in Perl or
what alternatives there are to the 1999 Time::ParseDate module.

Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

3

Yes, yes I am. Inevitably, as soon as I posted this message I noticed
that there’s a timezone field in the user table, though it isn’t exposed
in the UI and is defined as “varchar(50)” with no CHECK constraint, so
it’s not exactly clear what’s supposed to go in it.

If you go to “Logged in as …” → Settings → “About me” you can set
your own timezone in the Web UI.

In etc/RT_SiteConfig.pm you can set the global RT Server timezone. Look
at RT Config - RT 5.0.5 Documentation - Best Practical for
more infos.

Chris

4

Am 13.02.2013 14:19, schrieb Craig Ringer:

Yes, yes I am. Inevitably, as soon as I posted this message I noticed
that there’s a timezone field in the user table, though it isn’t exposed
in the UI and is defined as “varchar(50)” with no CHECK constraint, so
it’s not exactly clear what’s supposed to go in it.
If you go to “Logged in as …” → Settings → “About me” you can set
your own timezone in the Web UI.
Ah. It’s displayed there, but not in the admin-accessible user
configuration page at Tools->configuration->users->(Select user) . I
didn’t realise that the user-level one might have different (or more, at
least) fields to the admin one.

My apologies for the stupid question.

I was also hopelessly remiss in failing to report my RT version and
platform, something I should know better than. I’m using RT 4.0.7 on
Debian 6.0.6, with RT installed via Debian backports. I’m considering
updating to 4.0.10 soon.

I’m hoping other members of the team will have some updates to the
Spanish .po files to send in soon, since we’ll be focusing significantly
on Spanish support. Would Spanish versions of the default templates be
useful too?

Anyway, sorry for the waste of time. PEBKAC, ID10T error.

In etc/RT_SiteConfig.pm you can set the global RT Server timezone. Look
at RT Config - RT 5.0.5 Documentation - Best Practical for
more infos.
Yes, the default timezone is set to UTC in RT_SiteConfig .pm by

Set($Timezone, "UTC");

That’s in the basic documentation and that part is fine.

Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

5

Am 13.02.2013 14:19, schrieb Craig Ringer:

Yes, yes I am. Inevitably, as soon as I posted this message I noticed
that there’s a timezone field in the user table, though it isn’t exposed
in the UI and is defined as “varchar(50)” with no CHECK constraint, so
it’s not exactly clear what’s supposed to go in it.
If you go to “Logged in as …” → Settings → “About me” you can set
your own timezone in the Web UI.
Ah. It’s displayed there, but not in the admin-accessible user
configuration page at Tools->configuration->users->(Select user) . I
didn’t realise that the user-level one might have different (or more,
at least) fields to the admin one.

My apologies for the stupid question.

That said, from a usability point of view, the “Options” page could
really use a link to “About me”, particularly in the “Locale” and “Mail”
sections. The separation of display timezone and date format locale
seems really bizarre, and is part of why I didn’t find the option; if it
were supported, surely the timezone would be set in the user editor
accessible as admin, or in the Options section? It never occurred to me
to look in About Me.

Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

6

That said, from a usability point of view, the “Options” page could
really use a link to “About me”, particularly in the “Locale” and “Mail”
sections. The separation of display timezone and date format locale
seems really bizarre, and is part of why I didn’t find the option; if it
were supported, surely the timezone would be set in the user editor
accessible as admin, or in the Options section? It never occurred to me
to look in About Me.

There are internal reasons, of course, why this isn’t the case. They
aren’t good reasons though, and the timezone and language settings on a
user should be made visible from the user’s preferences page (rather
than the user properties page). The timezone property should also be
accessible to the admin user page. File a feature request, please, to
rt-bugs@bestpractical.com or http://issues.bestpractical.com.

Regarding your concerns about RT’s timezone support, they’re based on
false assumptions. RT uses the standard modern timezone specs and its
timezone support is pretty good. Best Practical has engineers scattered
around the world, so a tool without proper timezoning is not an option.
:slight_smile: The comment you dug out of the code is related to Time::ParseDate
itself, and describes RT’s workaround for it. Perl has very modern
date and timezone handling via the DateTime suite, but RT predates it by
quite a few years and hasn’t had the need to switch to it yet.

Thomas

7

At this point it’s a trial instance with low ticket volumes
and user counts, and RT’s paid support doesn’t really have a casual
entry-level option suitable for “we’re thinking of using RT, how would
you meet this requirement”.

For the record, we offer hourly consulting. Contact
sales@bestpractical.com if you’re interested.