<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
-new Date().getTimezoneOffset()/60;<br>
<br>
(this'll handle half- and quarter-hour timezones fine too).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Ideas/suggestions?<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre class="moz-signature" cols="72">--
Craig Ringer <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>
PostgreSQL Development, 24x7 Support, Training & Services</pre>
</body>
</html>