|  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
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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: aesthete at telecenter dot ru
New email:
PHP Version: OS:


 [2005-08-16 21:37 UTC] aesthete at telecenter dot ru
My previos message was about Wrong Time conersion from db:
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.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-28 12:17 UTC]
[20 Sep 11:13pm CEST]
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:

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

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]
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;
 [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]
[5 Feb 2006 12:15pm UTC] 
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=', '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/>";
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]
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:

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]
>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]
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]
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]
Not PHP problem -> bogus.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Mar 03 17:01:27 2024 UTC