Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Tim McDaniel (tmcdpanix.com)
Date: Tue Mar 04 2008 - 16:49:03 CST
On Tue, 4 Mar 2008, Jay Blanchard <jblanchardpocket.com> wrote:
> I had a bit of BFOTO and tried simple inserts.
> mysql> create table t (f timestamp);
> Query OK, 0 rows affected (0.00 sec)
> mysql> insert into t values ('2008-03-04 16:17:00');
> Query OK, 1 row affected (0.00 sec)
> mysql> select * from t;
> | f |
> | 2008-03-04 16:17:37 |
> 1 row in set (0.00 sec)
> The column type needs to be DATETIME.
Thank you for pointing me at TIMESTAMP versus DATETIME. I'll read
thoroughly when I can.
Can you give a little more detail as to why DATETIME is necessary?
Glancing briefly at
<http://dev.mysql.com/doc/refman/4.1/en/timestamp.html>, I see
Beginning with MySQL 4.1.3, the default current time zone for each
connection is the server's time. The time zone can be set on a
per-connection basis, as described in Section 9. but are converted
from the current time zone for storage, and converted back to the
current time zone for retrieval. >>>As long as the time zone
setting remains constant, you get back the same value you
store.<<< If you store a TIMESTAMP value, and then change the time
zone and retrieve the value, the retrieved value is different from
the value you stored. This occurs because the same time zone was
not used for conversion in both directions. The current time zone
is available as the value of the time_zone system variable.
In any event, the database has table definitions with columns like
`creation_ts` timestamp NOT NULL default CURRENT_TIMESTAMP on
Also, it's a Bugzilla database, and I'm not free to change the
Tim McDaniel, tmcdpanix.com
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql