On Tue, 4 Mar 2008, Jay Blanchard <[EMAIL PROTECTED]> wrote:
[snip] 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) [/snip] The column type needs to be DATETIME.
Thank you for pointing me at TIMESTAMP versus DATETIME. I'll read <http://dev.mysql.com/doc/refman/4.1/en/date-and-time-types.html> 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 (emphasis added): 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 update CURRENT_TIMESTAMP, Also, it's a Bugzilla database, and I'm not free to change the schema. -- Tim McDaniel, [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
