Seems like I was a bit too quick here.
MySQL doesn't support that stuff at all - you can only set global timezones.
PostgreSQL is compliant to 8601 according to the manual, but then again, the
manual tells me that using "T" won't work.
http://www.postgresql.org/docs/8.0/interactive/datatype-datetime.html has
information on how input has to look like. I'm not sure (and can't tell from
looking at the manual) if using a space in front of the offset value will
work.
The SQLite site doesn't have much information on the topic, but although
http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions talks about 8601
conformity, it apparently doesn't handle timezones.
SQL Server doesn't seem to support them either:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_
da-db_9xut.asp
All this needs testing, I guess.
- David
> -----Original Message-----
> From: Hans Lellelid [mailto:hans@xxxxxxxxx]
> Sent: Wednesday, April 06, 2005 10:49 PM
> To: dev@xxxxxxxxxxxxxxxxx
> Subject: Re: [creole-dev] RE: [creole-cvs] CVS update:
> /creole/creole/classes/creole/common/
>
> Hi David,
>
> Yes -- I was meaning to write list about this; good catch :)
>
> I think the right solution is to do ISO 8601, using date('c') formatter.
> I added the time zone using the +0400-type notation, which seemed to
> work on the databases I checked. I based that format on the postgres
> "timestamp with time zone" column type.
>
> So, you think ISO 8601 using the 2005-04-06T20:35:23+01:00 format should
> be well-supported?
>
> If so, I'll make this change.
>
> I need to be able to store time stamps with time zones for a project I'm
> doing, and I assume others will have this need also. For databases that
> don't care, hopefully they just ignore (and don't convert) the time zone.
>
> -Hans
>
> David Zülke wrote:
> > Is the format supposed to follow ISO 8601?
> >
> > ISO 8601 defines a full date/time/offset representation like follows:
> >
> > 2005-04-06T20:35:23+01 or
> > 2005-04-06T20:35:23+01:00 or
> > 2005-04-06T19:35:23Z or
> > 20050406T203523+0100 etc etc
> >
> > For more examples see http://www.pvv.org/~nsaa/8601v2000.pdf
> >
> > (I was just wondering about this because the bug report on issues@ said
> > something about 8601)
> >
> > Also, there's the question how the different RDBMS return these
> values...
> > always as UTC w/o any timezone information, always as UTC with ending
> "Z",
> > always in the timezone as entered, always with local timezone...?
> >
> > - David
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: hlellelid@xxxxxxxxxx [mailto:hlellelid@xxxxxxxxxx]
> >>Sent: Tuesday, April 05, 2005 10:00 PM
> >>To: cvs@xxxxxxxxxxxxxxxxx
> >>Subject: [creole-cvs] CVS update: /creole/creole/classes/creole/common/
> >>
> >>User: hlellelid
> >>Date: 05/04/05 12:59:43
> >>
> >>Modified:
> >> /creole/creole/classes/creole/common/
> >> PreparedStatementCommon.php
> >>
> >>Log:
> >> [PLEASE HELP TEST]
> >>
> >> Adding additional timezone information to the way the timestamp
> >>formatting in setTimestamp()
> >>
> >> * MySQL simply ignores this (which is fine).
> >> * Postgres will use this info if using 'timestamp with time zone'
> column
> >>type.
> >>
> >> Behavior on SQLite and MSSQL currently unknown. Since the timezone is
> >>part of the ISO standard format, hopefully those databases will simply
> >>ignore it.
> >>
> >>File Changes:
> >>
> >>Directory: /creole/creole/classes/creole/common/
> >>================================================
> >>
> >>File [changed]: PreparedStatementCommon.php
> >>Url:
> >>http://creole.tigris.org/source/browse/creole/creole/classes/creole/comm
> on
> >>/PreparedStatementCommon.php?r1=1.11&r2=1.12
> >>Delta lines: +5 -6
> >>-------------------
> >>--- PreparedStatementCommon.php 29 Mar 2005 16:56:10 -0000 1.11
> >>+++ PreparedStatementCommon.php 5 Apr 2005 19:59:43 -0000 1.12
> >>@@ -1,6 +1,6 @@
> >> <?php
> >> /*
> >>- * $Id: PreparedStatementCommon.php,v 1.11 2005/03/29 16:56:10 gamr
> Exp
> >>$
> >>+ * $Id: PreparedStatementCommon.php,v 1.12 2005/04/05 19:59:43
> hlellelid
> >>Exp $
> >> *
> >> * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> >> * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> >>@@ -28,7 +28,7 @@
> >> * to work with BLOB and CLOB values w/o needing special LOB-specific
> >>routines.
> >> *
> >> * @author Hans Lellelid <hans@xxxxxxxx>
> >>- * @version $Revision: 1.11 $
> >>+ * @version $Revision: 1.12 $
> >> * @package creole.common
> >> */
> >> abstract class PreparedStatementCommon {
> >>@@ -591,12 +591,11 @@
> >> */
> >> function setTimestamp($paramIndex, $value)
> >> {
> >>-
> >> if ($value === null) {
> >> $this->setNull($paramIndex);
> >> } else {
> >>- if (is_numeric($value)) $value = date('Y-m-d H:i:s',
> >>$value);
> >>- elseif (is_object($value)) $value = date("Y-m-d H:i:s",
> >>$value->getTime());
> >>+ if (is_numeric($value)) $value = date('Y-m-d H:i:s O',
> >>$value);
> >>+ elseif (is_object($value)) $value = date("Y-m-d H:i:s
> >
> > O",
> >
> >>$value->getTime());
> >> $this->boundInVars[$paramIndex] = "'".$this-
> >>
> >>>escape($value)."'";
> >>
> >> }
> >> }
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: cvs-unsubscribe@xxxxxxxxxxxxxxxxx
> >>For additional commands, e-mail: cvs-help@xxxxxxxxxxxxxxxxx
> >>
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxx
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxx
>
|
