
I'm currently evaluating OTRS and have a first question:
Is it true, that OTRS gets the current time from the database server?
If so, is there a way to define an offset?
If not, I'd plead to make this two configuration options:
- time offset of database server (or better get time with gmtime())
- time offset of OTRS (or better let agents and customers define their
time zones).
My MySQL server runs on GMT(*) - calculating local time belongs to the
application.
(*) because
- we have a world wide Internet
- I don't want my database server to skip or insert an hour twice a year
when switching from and to daylight saving time (imagine your telco
did this while doing a call ;-).
--
Bernhard Graf

Great idea - also the ability to change the date format would be nice. The default in ticket view is mm/dd/yyyy. OK if you're used to that format, but very confusing if you're more accustomed to dd/mm/yyyy (or yyyy/mm/dd).
I'm currently evaluating OTRS and have a first question:
Is it true, that OTRS gets the current time from the database server? If so, is there a way to define an offset? If not, I'd plead to make this two configuration options: - time offset of database server (or better get time with gmtime()) - time offset of OTRS (or better let agents and customers define their time zones).
My MySQL server runs on GMT(*) - calculating local time belongs to the application.
(*) because - we have a world wide Internet - I don't want my database server to skip or insert an hour twice a year when switching from and to daylight saving time (imagine your telco did this while doing a call ;-).
-- Bernhard Graf
_______________________________________________ OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs Support oder Consulting für Ihr OTRS System? => http://www.otrs.de/
-------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R59. Free WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails Phone Now! 086 11 11 440

Hi Henry, On Wed, Feb 18, 2004 at 01:38:21PM +0200, henry@metroweb.co.za wrote:
Great idea - also the ability to change the date format would be nice. The default in ticket view is mm/dd/yyyy. OK if you're used to that format, but very confusing if you're more accustomed to dd/mm/yyyy (or yyyy/mm/dd).
This can be done by the translation file: [Kernel/Language/en.pm] $Self->{DateFormat} = '%M/%D/%Y %T'; $Self->{DateFormatLong} = '%A %B %D %T %Y'; $Self->{DateInputFormat} = '%M/%D/%Y'; $Self->{DateInputFormatLong} = '%M/%D/%Y - %T'; [...] Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

Hi Bernhard, On Wed, Feb 18, 2004 at 12:21:33PM +0100, Bernhard Graf wrote:
I'm currently evaluating OTRS and have a first question:
Is it true, that OTRS gets the current time from the database server?
Yes.
If so, is there a way to define an offset?
No.
If not, I'd plead to make this two configuration options: - time offset of database server (or better get time with gmtime()) - time offset of OTRS (or better let agents and customers define their time zones).
I put it on the todo list.
Bernhard Graf
Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

On Wed, Feb 18, 2004 at 09:06:58PM +0100, Bernhard Graf wrote:
Is it true, that OTRS gets the current time from the database server?
Yes.
I'm curious: Why?
Because of the time functions of the database.
Bernhard Graf
Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

On Wednesday 18 February 2004 22:17, Martin Edenhofer wrote:
Is it true, that OTRS gets the current time from the database server?
Yes.
I'm curious: Why?
Because of the time functions of the database.
I'm not sure if I understand this.
What functions do MySQL *and* PostgreSQL (and all other possible DB
servers) provide that Perl (and packages) don't?
ATM I can only see disadvantages with this (as described in my first
post).
--
Bernhard Graf

On Wed, Feb 18, 2004 at 10:26:46PM +0100, Bernhard Graf wrote:
I'm curious: Why?
Because of the time functions of the database.
I'm not sure if I understand this.
What functions do MySQL *and* PostgreSQL (and all other possible DB servers) provide that Perl (and packages) don't?
ATM I can only see disadvantages with this (as described in my first post).
For example: SELECT id FROM ticket AND create_time < '2003-01-01 01:01' In this cases the database time function is used. All other time functions are implemented in perl (Date::Calc).
Bernhard Graf
Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

On Wednesday 18 February 2004 22:41, Martin Edenhofer wrote:
What functions do MySQL *and* PostgreSQL (and all other possible DB servers) provide that Perl (and packages) don't?
ATM I can only see disadvantages with this (as described in my first post).
For example: SELECT id FROM ticket AND create_time < '2003-01-01 01:01'
In this cases the database time function is used. All other time functions are implemented in perl (Date::Calc).
I don't see a database function in the above SQL statement.
Despite I would expect additional trouble when time (and time zones) on
OTRS host and SQL host differ.
--
Bernhard Graf
participants (3)
-
Bernhard Graf
-
henry@metroweb.co.za
-
Martin Edenhofer