I found something on the odbc list that suggested creating your field as a
timestamp(0) rather than letting it default to timestamp(6).
-ron
> -----Original Message-----
> From: Chris Gamache [mailto:cgg007@yahoo.com]
> Sent: Wednesday, May 08, 2002 10:48 AM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] timestamp in 7.1 vs 7.2
>
>
> data=# begin work;
> BEGIN
> data=# create temporary table tstest (tsvalue timestamp);
> CREATE
> data=# insert into tstest (tsvalue) values (current_timestamp);
> INSERT 29700913 1
> data=# select * from tstest;
> tsvalue
> -------------------------------
> 2002-05-08 13:34:23.809817-04
> (1 row)
>
> data=# select * from tstest where tsvalue='5/8/02 1:34:23
> PM'::timestamp;
> tsvalue
> ---------
> (0 rows)
>
> data=# rollback;
> ROLLBACK
> data=#
>
> =========================================
>
> It seems like we now have microseconds to deal with in the
> timestamp from 7.1.
> (Or I've just been doing most of my timestamp processing on
> the client-end as
> opposed to letting postgresql set them. never gave it the
> chance to not match
> up...)
>
> Unfortunately, ODBC reformats the timestamp to something
> similar to the above
> select...where statement. Can I cast current_timestamp to truncate the
> microseconds?
>
> Any other ideas for matching up the data properly? I only
> need up-to-the-second
> resolution on this particular timestamp task.
>
> CG
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
>