php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34158 Wrong t.tm_isdst flag value.
Submitted: 2005-08-16 21:37 UTC Modified: 2007-04-20 07:09 UTC
Votes:8
Avg. Score:4.5 ± 0.9
Reproduced:6 of 6 (100.0%)
Same Version:1 (16.7%)
Same OS:4 (66.7%)
From: aesthete at telecenter dot ru Assigned:
Status: Not a bug Package: InterBase related
PHP Version: 4.4.0/5.x.x OS: Linux 2.6.12 (Fedora Core 3)
Private report: No CVE-ID: None
 [2005-08-16 21:37 UTC] aesthete at telecenter dot ru
Description:
------------
My previos message was about Wrong Time conersion from db:
http://bugs.php.net/bug.php?id=34037&edit=1
I solved my problem when comment t.tm_isdst = -1; in interbase.c

I don't know is there bug of php or interbase but i have some ideas abot it.

In interbase.c we have some code:
/*
   XXX - Might have to remove this later - seems that isc_decode_date()
   always sets tm_isdst to 0,
   sometimes incorrectly (InterBase 6 bug?)
*/
t.tm_isdst = -1;

As you say in your comment:
"isc_decode_date() always sets tm_isdst to 0" ... thats true.

But in gds.cpp (firebird 1.5.2 source) nothing said about changeing tm_isdst (in all gds.cpp)
to any value Except for 0 in memset(times, 0, sizeof(*times)) instructions. 
It always return tm_isdst = 0 in all api functions where "struct tm *times" used as argument! 

I dont know why you do t.tm_isdst = -1; 
Therefore strftime(string_data, sizeof(string_data), format, &t) cannot return right formated time string. 

May be it php bug ?)

P.S.: Sorry my english.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-28 12:17 UTC] tony2001@php.net
[20 Sep 11:13pm CEST] sniper@php.net
Can you please give a try for the PDO driver?
 [2006-01-17 15:05 UTC] c dot coppari at sintekno dot it
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().
 [2006-02-05 11:57 UTC] aesthete at telecenter dot ru
In php-5.1.2 this bug too ...
 [2006-02-05 12:15 UTC] tony2001@php.net
Did you try PDO_FIREBIRD ?
 [2006-02-13 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2006-09-17 09:49 UTC] mario dot perazzoli at tiscali dot it
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
 [2007-04-08 22:21 UTC] aesthete at telecenter dot ru
Is this bug will be fixed ?
 [2007-04-08 22:23 UTC] aesthete at telecenter dot ru
-
 [2007-04-09 20:41 UTC] tony2001@php.net
[5 Feb 2006 12:15pm UTC] tony2001@php.net 
Did you try PDO_FIREBIRD ?
 [2007-04-10 16:11 UTC] aesthete at telecenter dot ru
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.
 [2007-04-10 16:23 UTC] tony2001@php.net
Why do you think it should return non-empty string?
Did you try to run this query using other interfaces to Interbase?
 [2007-04-11 19:28 UTC] aesthete at telecenter dot ru
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 ?
 [2007-04-11 19:39 UTC] tony2001@php.net
>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.
 [2007-04-12 14:14 UTC] aesthete at telecenter dot ru
Ok .. what i must do to become maintainer of ext/interbase ? ...
 [2007-04-12 14:50 UTC] tony2001@php.net
Fix this bug for example?
 [2007-04-12 16:03 UTC] aesthete at telecenter dot ru
Ok ... my first patch will be:
// t.tm_isdst = -1; 
in ext/ibase_query.c in line 1376 
... how can i apply this patch ?
 [2007-04-17 10:39 UTC] abies@php.net
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 :-)


 [2007-04-19 21:15 UTC] aesthete at telecenter dot ru
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.
 [2007-04-20 07:09 UTC] tony2001@php.net
Not PHP problem -> bogus.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sat Nov 28 06:01:24 2020 UTC