I am wondering how Mantis uses unix_timestamp generally enough so that
is works with all databases. I need to support Scmbug integrating with
Mantis 1.2.0 properly, and I am not sure how I should do that.
Currently, Scmbug issues SQL statements directly to the Mantis database
for its integration, due to a lock of a general API that could be used
Thanks for any help.
-------- Forwarded Message --------
From: Kristis Makris <mkgnu@...>
To: Martin Fuchs <martin-fuchs@...>
Subject: Re: [scmbug-users] Scmbug and Mantis 1.2.0
Date: Sun, 07 Mar 2010 15:49:39 -0700
Martin, unix_timestamp() is not available for postgres, or other
databases. I am not sure what is the best way to handle this. I wonder
how the Mantis developers handle it.
On Sun, 2010-02-28 at 11:29 +0100, Martin Fuchs wrote:
> there is now the new Mantis release 1.2.0:
> One change includes this:
> - Migrated away from DATETIME fields to integer timestamps for timezone usage
> To become compatible to this new version, Scmbug should be changed to set all date fields to unix_timestamp() instead of now() when inserting new rows in the Mantis MySQL database.
> scmbug-users mailing list
scmbug-users mailing list
From: John Reese <jreese@le...> - 2010-03-08 00:48:04
Kristis Makris wrote:
> I am wondering how Mantis uses unix_timestamp generally enough so that
> is works with all databases. I need to support Scmbug integrating with
> Mantis 1.2.0 properly, and I am not sure how I should do that.
> Currently, Scmbug issues SQL statements directly to the Mantis database
> for its integration, due to a lock of a general API that could be used
> from Perl.
> Thanks for any help.
Basically, MantisBT now expects any date or time field to be defined as an
INTEGER type. This allows easier handling of timezone conversions, as well as a
better method of handling "null" dates, which we consider to be 1 (one). If you
would like more details, take a look at core/date_api.php for some of the
routines we use for handling date fields.