rt/docs/timezones_in_charts.pod

   1 =head1 INTRO
   2
   3 Every date in RT's DB is stored in UTC format. This affects charts
   4 grouped by time periods (Annually, Monthly, etc.). To produce
   5 charts that are in a specific timezone we have to use database specific
   6 functions to convert time. Each DB has very different requirements.
   7
   8 =head1 CONFIGURATION
   9
  10 This code is experimental and you can turn it on and off using
  11 boolean option $ChartsTimezonesInDB in the RT config.
  12
  13 =head1 DATABASE SPECIFIC NOTES
  14
  15 =head2 mysql
  16
  17 Time can not just be converted using numeric time shift as this
  18 shift value depends on daylight saving time properties of the time zone.
  19
  20 mysql since 4.1.3 supports named timezones, but you have to fill
  21 special tables with up to date data. On modern systems it's Usually
  22 very easy:
  23
  24     mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql
  25
  26 mysql's doc recommends to restart server. Read more about timezones
  27 in mysql in the following document
  28 http://dev.mysql.com/doc/refman/5.0/en/time-zone-support.html .
  29
  30 =head2 PostgreSQL
  31
  32 PostgreSQL database uses your operating system's functions to convert
  33 timezones.  You don't need to do anything in particular except making
  34 sure that the data in F</usr/share/zoneinfo> is up to date. On some
  35 systems this means upgrading a system package.
  36
  37 =head3 Note for users of Pg 7.2 and older or users upgraded from those
  38
  39 You should be sure that timestamps in RT DB have no TZ set. TIMESTAMP
  40 column type in PostgreSQL prior to Pg 7.3 has timezone info by default.
  41 In newer versions it's not the case anymore. If your RT database has
  42 this embedded timezone info, you need to alter the columns before
  43 enabling this feature.
  44
  45 =head2 Other databases
  46
  47 There is no implementation for other DBs, yet.
  48
  49 =head1 FOR DEVELOPERS
  50
  51 =head2 PostgreSQL
  52
  53 We use timestamp type for all datetime fields. It either has timezone
  54 info or not, by default since Pg 7.3 it has no timezone. Conversion is
  55 kinda tricky:
  56
  57     timezone('Europe/Moscow', timezone('UTC', column_without_tz_info))
  58     timezone('to_tz', timezone('from_tz', column_without_tz_info))
  59     http://www.postgresql.org/docs/7.4/static/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT
  60
  61 This function flips HAS_TZ flag on the argument. First call makes
  62 no conversion, but flips HAS_TZ flag. So next call flips it back
  63 and does actual conversion.
  64
  65 http://www.postgresql.org/docs/7.4/static/datatype-datetime.html#DATATYPE-TIMEZONES
  66
  67 =head2 mysql
  68
  69 Once timezone information is loaded into tables on the server,
  70 we have all the same set of named timezones in the system
  71 and DateTime (DateTime project has copy of the TZ data in a module).
  72
  73 CONVERT_TZ(TS, from, to) exists since mysql 4.1.3. Note that it
  74 takes timestamp, so supports limitted range (usuall 1970-2038).
  75
  76 =head2 Oracle
  77
  78 Look at FROM_TZ function.
  79
  80 =head2 SQLite
  81
  82 As far as I can see has no support.
  83
  84 =cut