<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/13/2013 08:13 PM, Craig Ringer
wrote:<br>
</div>
<blockquote cite="mid:511B8380.8010101@2ndquadrant.com" type="cite">
<br>
Am I missing something?<br>
</blockquote>
<br>
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.<br>
<br>
perldoc RT::User says:<br>
<br>
"Returns the current value of Timezone. (In the database, Timezone
is stored as varchar(50).)"<br>
<br>
... which is totally uninformative. <br>
<br>
I found a comment in Date.pm saying that:<br>
<br>
require Time::ParseDate;<br>
# the module supports only legacy timezones like PDT or
EST...<br>
# so we parse date as GMT and later apply offset, this only<br>
# should be applied to absolute times, so compensate shift
in NOW<br>
<br>
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.<br>
<br>
A look at the perldoc for Time::ParseDate suggests that it also
understands UTC offsets, which are at least unambiguous:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://search.cpan.org/%7Emuir/Time-modules-2003.0211/lib/Time/ParseDate.pm#Timezone_formats:">
http://search.cpan.org/~muir/Time-modules-2003.0211/lib/Time/ParseDate.pm#Timezone_formats:</a><br>
<br>
but no support for modern timezone specs like Australia/Perth that
auto-adjust to DST based on tzdata rules.<br>
<br>
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.<br>
<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>