[20 Sep 11:13pm CEST] sniper@php.net
Can you please give a try for the PDO driver?

I think the problem is in mktime() function, at line:

  timestamp = mktime(&t);

This is because the variable t for SQL_TYPE_TIME doesn't get the proper values for month, year and day.
The mktime() function tries to normalize the date, however with libc6 this result in an incorrect time.

I used this patch:

case SQL_TYPE_TIME:
  isc_decode_sql_time((ISC_TIME *) data, &t);
  format = IBG(timeformat);
  t.tm_mday = 16;
  t.tm_mon = 0;
  t.tm_year = 106;
  break;

Forcing the day, month and year with a correct value solved the problem for me.
I don't know if this is the correct behaviour of mktime().

In php-5.1.2 this bug too ...

Did you try PDO_FIREBIRD ?

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I think the bug is related with an other bug into libc: in the version 4 and 5 of fedora core distribution, strftime don't work correctly with tm_isdst = -1 (undefined). 
My question is: whi ib/fb should return another value ather than 0 for tm_isdst?
I have been solved the bug whith a comment to the row t.tm_isdst = -1;
regards

Is this bug will be fixed ?

-

[5 Feb 2006 12:15pm UTC] tony2001@php.net 
Did you try PDO_FIREBIRD ?

Ok ... some code:

try {
    $dbh = new PDO ('firebird:dbname=10.0.0.1:/home/dbase/prihod/zakupka.gdb', 'SYSDBA', '1');
   foreach ($dbh->query('SELECT NAME FROM CARS ORDER BY NAME') as $row) 
   {
      echo $row['NAME'].'<br>';
   }
   $dbh = null;
} catch (PDOException $e) {
   print "Error!: " . $e->getMessage() . "<br/>";
   die();
  }
Return right strings.

But when i try 'SELECT GEN_ID(GEN_DOSTAVKA_ID,1) FROM RDB$DATABASE' with  echo $row['GEN_ID'].'<br>';
nothing return. Probably bug.

Why do you think it should return non-empty string?
Did you try to run this query using other interfaces to Interbase?

Tony ... this is simple query which return next value of generator GEN_DOSTAVKA_ID ... on other interfaces like isql or Ibexpert it return right values ... may be you see my previos bug: http://bugs.php.net/bug.php?id=41025

But #34158 bug not about this PDO driver ... can we solve problem with wrong t.tm_isdst = -1; value ?

>can we solve problem with wrong t.tm_isdst = -1; value ?
Sure we can.
The problem is that ext/interbase author doesn't maintain the extension anymore, so you'll have to wait for someone who has enough knowledge and desire to take it over.
This "someone" might be you, of course, you seem to be the only person actively using Interbase I know of.

Ok .. what i must do to become maintainer of ext/interbase ? ...

Fix this bug for example?

Ok ... my first patch will be:
// t.tm_isdst = -1; 
in ext/ibase_query.c in line 1376 
... how can i apply this patch ?

Can you explain (again) why setting isdst to -1 is erroneous? In my opinion, the mktime(3) man page says that isdst==-1 signifies that dst info is unavailable, which is exactly the case as libgds always returns zero, dst or no dst.

So did anything change in libc in the meantime? Anything the tests have missed before? Just commenting out a line because it fixes a specific case is not the way to go, in my opinion. Especially not in the case of UNIX/timestamp/mktime/etc related issues :-)

Yes your right. I test this bug on Fedora core 3 where glibc-2.3.5.
On Fedora core 6 glibc-2.5 and this bug does not appear. Perhaps there was a glibc bug or bug in putches to glibc which fc team make.
I tested latest dev php version ... Thanks.

Not PHP problem -> bogus.