[Dbix-class] Calling all database champions

[Nathan Gray]

On Sat, May 26, 2007 at 02:22:44PM +0100, Matt S Trout wrote:
> On Sat, May 26, 2007 at 08:30:29AM -0400, Jason Kohles wrote:
> > On May 23, 2007, at 8:04 PM, Tom Lanyon wrote:
> > >
> > PostgreSQL has more than one timestamp type, which may show up in the  
> > column_info as:
> > 
> > timestamp with time zone
> > timestamp without time zone
> > timestamp
> > timestamptz
> 
> And none of those need special handling?
> 
> Peopl who champion a specific DB engine, how would this work for you?
> 
> I'm getting increasingly tempted to just sod it and apply jason's patch
> when he sends out a test case or two for it and we'll see what happens.

Oracle also has several date types.  However, with PostgreSQL, setting
the date format only affects display (supplying a date in any of the
valid formats works).  In Oracle, setting the date format affects both
display and parsing (a date supplied to the database must match the
date format currently in effect).

To complicate matters further (or simplify, depending on your point of
view), each Oracle date type format is set independently.  So setting
the format for a 'date' does not affect the format for 'timestamp'.

Also, unfortunate for Perl's DateTime, the Oracle date types are named
somewhat strangely.

  DATE                    # date and time
  TIMESTAMP               # date and time with sub-second granularity
  TIMESTAMP WITH TIMEZONE # timestamp with timezone information

In the DateTime::Format::Oracle module, 'parse_date' and
'parse_datetime' are synonymous, because an Oracle date really is a
datetime.

I have hopes to implement methods 'parse_timestamp' and
'parse_timestamp_with_timezone'.

For Oracle, it would be best if DBIC date inflation looks at the full
date datatype, such as:

  DATE
  TIMESTAMP
  TIMESTAMP WITH LOCAL TIMEZONE
  TIMESTAMP WITH TIMEZONE

and looks for methods which are specific enough:

  parse_date
  parse_timestamp
  parse_timestamp_with_local_timezone
  parse_timestamp_with_timezone

If there is no exact match, look for methods which are less specific:

  parse_timestamp_with_local_timezone
  -> parse_timestamp_with_timezone
  -> parse_timestamp
  (-> parse_datetime)?

Each DateTime::Format::* class should then implement the generic
'parse_date' and 'parse_datetime' methods, as well as methods for each
database specific date type.

-kolibrie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070529/a1da2de6/attachment.pgp