[dev] feature request : monthdayyear $format_in which use strftime()

[Matthieu Foillard]

this works for me : 

Index: Driver/sql.php
===================================================================
RCS file: /repository/turba/lib/Driver/sql.php,v
retrieving revision 1.30
diff -u -3 -p -r1.30 sql.php
--- Driver/sql.php      10 Feb 2003 15:53:47 -0000      1.30
+++ Driver/sql.php      16 Apr 2003 14:27:58 -0000
@@ -39,6 +39,9 @@ class Turba_Driver_sql extends Turba_Dri
             $this->errstr = $this->db->getMessage();
         }

+       if($params['phptype'] == 'oci8')
+         $this->db->query("ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD'");
+
         $this->table = $params['table'];
     }

In fact, the date display now correctly when viewing a contact but when i try 
do modify the date, it does not update anything. Any ideas please ?



Le Mercredi 16 Avril 2003 04:11, Marko Djukic a écrit :
> Quoting Matthieu Foillard <m.foillard at photoways.com>:
> > Be able to specify $format_in using strftime() format so that i can hold
> > date in any format like oci8 date, e.g. 17-OCT-78
>
> ok i have a bit of a dilemma with this problem:
>
> the trouble of having a format_in specifiable with strftime() type string
> would mean that the code would have to know how to parse an incoming
> variable (in any variety of strftime() formats) into month day and year
> components for use in the form. it doesn't look like a minor tweak to get
> this working.
> at the moment this is limited to just three types as supported by PEAR's
> Date.php plus the yyyy-mm-dd format which is not supported by PEAR, but an
> extra check was added in the Form.php code.
>
> 1. move entirely to specifiying a strftime() type format for storing
> monthdayyear values, but then we'd need another layer of translation code
> to get it parsed into components. doesn't sound like a good idea.
>
> 2. add another format dd-MMM-yy to the Form.php (outside of PEAR) code?
> don't particularly like this sitting on the fence half using Date.php half
> not using it. i'd prefer using entirely the one date class or if it's not
> up to it then creating our own? or submitting a patch for PEAR perhaps?
>
> 3. plus are there other obvious date formats used by other DBs that are
> being missed here?
>
> 4. any other solutions?
>
> i have no experience with oci8 but apparently one other solution is to set
> oci8 to use plain old sql date format (which would seem to be the best
> alternative for now rather than turning upsidedown the monthdayyear code
> yet again): http://www.zend.com/tips/tips.php?id=96&single=1
>
> marko