RT (Request Tracker) Date Handling

Scott Penrose scottp at dd.com.au
Sat Nov 8 17:29:29 CST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have confirmed that it is all RT's fault.

There are a number of ways of entering dates into a database (in this 
case mysql). If you enter a date directly simply (eg: "2003-11-01 
23:14") then it assumes it is the local time which is setup on the 
system (this default behaviour can be changed, but normally it SHOULD 
be this way).

However, you can also tell it the timezone, or even the GMT or even the 
Unix Time Stamp. All of these work perfectly in mysql - as they should.

All (sensible) databases store the dates normalised in GMT format and 
store the offset, so that it can be asked back in any format you want.

RT however expects that the default behaviour of a database be changed 
to accept strings as assumed to be in GMT. It then converts them back 
on output.

For those developing databases you should do either read/write to the 
database in GMT time and convert, or let the database do it for  you - 
not both. Mysql has some great methods for asking the time in the 
format you want.

We have a solution we are about to try which is to tell the mysql 
database that it always receives and should return dates in GMT unless 
specifically asked - although this will solve my problem - it means 
that everyone with a spreadsheet or any other means of doing the query 
will be getting GMT - and have to convert every date (not an easy task 
in Excel etc). My code fortunately will be unaffected as it always only 
deals with unix time stamps and converts only on output - as I don't 
care at this stage about time zone. The problem is of course that all 
the dates are probably going to come out wrong out of the database.

Anyway - this is all just an FYI so that future development of date 
handling in databases is done properly :-)

Scooter
- -- 
Scott Penrose
Anthropomorphic Personification Expert
http://search.cpan.org/search?author=SCOTT
scott at cpan.org

Dismaimer: While every attempt has been made to make sure that this 
email only contains zeros and ones, there has been no effort made to 
guarantee the quantity or the order.

Please do not send me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE/rXxcDCFCcmAm26YRAhRmAJwM27ZdBCdi1FceSkavBrdPLRZTEACfaHrm
J4qRtO+0yVBSxy28/aKBahY=
=Ed2X
-----END PGP SIGNATURE-----




More information about the Melbourne-pm mailing list