Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40739 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83185 invoked from network); 27 Sep 2008 21:05:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Sep 2008 21:05:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=ilia.cheishvili@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ilia.cheishvili@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.14 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: ilia.cheishvili@gmail.com X-Host-Fingerprint: 209.85.217.14 mail-gx0-f14.google.com Received: from [209.85.217.14] ([209.85.217.14:38215] helo=mail-gx0-f14.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DD/27-42505-700AED84 for ; Sat, 27 Sep 2008 17:05:12 -0400 Received: by gxk7 with SMTP id 7so9236948gxk.23 for ; Sat, 27 Sep 2008 14:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=b8uUYQ8TTqT9u8HIQCAeLm70CyNhzTP7Burffk1tTqg=; b=G7hzu2f8d36GX1/hsGMm4WcBMJOgdhopLEsSjRUMyY7KzArUB6O7i//X5Jj36Ryby4 XyS/Q4me3cQYdiSbBn0Vwp7IEjnfpQXBLGo58mLzHmiweapN+vxIFvY4H/awiY90rStp 0gjVfjgFSGSCuKlyPN7xStgTMusMaowvxvGmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=CN2ysgfTM7T5BF9MHz7Wu30jX0cL5NxdXFbuwwEgEXI5slgUKsufcFECGQWJrxEM5t LCwDe/0tEzVlU1wR/3UCMp3CW2Y3SCa0S1+PB/RJoBVhQ4vL5W4nn0wwtWxNWECnMSaJ fFAhRD+EQwyOD/S60DCAx4zL9/1eZPIe3vZDc= Received: by 10.151.109.17 with SMTP id l17mr4689634ybm.20.1222549508878; Sat, 27 Sep 2008 14:05:08 -0700 (PDT) Received: by 10.151.144.11 with HTTP; Sat, 27 Sep 2008 14:05:08 -0700 (PDT) Message-ID: Date: Sat, 27 Sep 2008 15:05:08 -0600 To: "Alexey Zakhlestin" Cc: "PHP internals" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_21830_24067706.1222549508848" References: Subject: Re: [PHP-DEV] [PATCH] Fix date() bug From: ilia.cheishvili@gmail.com ("Ilia Cheishvili") ------=_Part_21830_24067706.1222549508848 Content-Type: multipart/alternative; boundary="----=_Part_21831_4884611.1222549508848" ------=_Part_21831_4884611.1222549508848 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I did some digging around in the code and came up with the solution that you suggested. I put the fix in unixtime2tm.c, letting php_date.c remain the nice abstraction layer between the system-dependent code of getting the time and actually formatting it for display. The patch is attached. Thanks for the back and forth thus far :) Ilia On Sat, Sep 27, 2008 at 3:21 AM, Alexey Zakhlestin wrote: > On Sat, Sep 27, 2008 at 12:26 PM, Ilia Cheishvili > wrote: > > Ah, I see. I like that even better :) > > And I attached yet another patch that incorporates your idea. > > thanks. > I did some more code-digging, and it looks, like proper point for > fixing is not here, anyway. > > It should be in timelib_unixtime2gmt() and timelib_unixtime2local() > funcitons of ext/date/lib/unixtime2tm.c > "->f" member of structure is not set there, which results in zero's in > output. > > date() function is an abstraction and should not deal with such details > itself. > > > > > On Sat, Sep 27, 2008 at 2:20 AM, Alexey Zakhlestin > > wrote: > >> > >> On Sat, Sep 27, 2008 at 12:04 PM, Ilia Cheishvili > >> wrote: > >> > It definitely would be, and that's actually the way I would have > >> > preferred > >> > to do it. I didn't want to impact too much code, if that makes sense > in > >> > this case, but I'm glad that someone agrees :) > >> > I have attached a patch to do exactly this. > >> > >> I was thinking other in another direction.. > >> > >> case 'u': > >> #ifdef HAVE_GETTIMEOFDAY > >> gettimeofday(&tp, &tz); > >> length = slprintf(buffer, 32, "%06d", (int) tp.tv_usec); > >> #else > >> length = slprintf(buffer, 32, "%06d", (int) floor(t->f * 1000000)); > >> #endif > >> break; > >> > >> > >> > > >> > On Sat, Sep 27, 2008 at 1:40 AM, Alexey Zakhlestin < > indeyets@gmail.com> > >> > wrote: > >> >> > >> >> On Sat, Sep 27, 2008 at 11:04 AM, Ilia Cheishvili > >> >> wrote: > >> >> > Hi all, > >> >> > This patch addresses the issue with the date() function. When > >> >> > passing > >> >> > in a > >> >> > 'u', the date() function simply outputs six zeros. To fix this, I > >> >> > added > >> >> > a > >> >> > gettimeofday() call that figures out what to display for > >> >> > microseconds. > >> >> > I am > >> >> > including the headers and using the function with pre-processor > >> >> > safeguards > >> >> > as well. > >> >> > Take a look :) > >> >> > >> >> Wouldn't it be better, to make gettimeofday() call only in case of > 'u'? > >> >> > >> >> > >> >> -- > >> >> Alexey Zakhlestin > >> >> http://blog.milkfarmsoft.com/ > >> > > >> > > >> > >> > >> > >> -- > >> Alexey Zakhlestin > >> http://blog.milkfarmsoft.com/ > > > > > > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ > ------=_Part_21831_4884611.1222549508848 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I did some digging around in the code and came up with the solution that you suggested.  I put the fix in unixtime2tm.c, letting php_date.c remain the nice abstraction 
layer between the system-dependent code of getting the time and actually formatting it for display.  The patch is attached.

Thanks for the back and forth thus far :)

Ilia

On Sat, Sep 27, 2008 at 3:21 AM, Alexey Zakhlestin <indeyets@gmail.com> wrote:
On Sat, Sep 27, 2008 at 12:26 PM, Ilia Cheishvili
> Ah, I see.  I like that even better :)
> And I attached yet another patch that incorporates your idea.

thanks.
I did some more code-digging, and it looks, like proper point for
fixing is not here, anyway.

It should be in timelib_unixtime2gmt() and timelib_unixtime2local()
funcitons of ext/date/lib/unixtime2tm.c
"->f" member of structure is not set there, which results in zero's in output.

date() function is an abstraction and should not deal with such details itself.

>
> On Sat, Sep 27, 2008 at 2:20 AM, Alexey Zakhlestin <indeyets@gmail.com>
> wrote:
>>
>> On Sat, Sep 27, 2008 at 12:04 PM, Ilia Cheishvili
>> <ilia.cheishvili@gmail.com> wrote:
>> > It definitely would be, and that's actually the way I would have
>> > preferred
>> > to do it.  I didn't want to impact too much code, if that makes sense in
>> > this case, but I'm glad that someone agrees :)
>> > I have attached a patch to do exactly this.
>>
>> I was thinking other in another direction..
>>
>> case 'u':
>> #ifdef HAVE_GETTIMEOFDAY
>>    gettimeofday(&tp, &tz);
>>    length = slprintf(buffer, 32, "%06d", (int) tp.tv_usec);
>> #else
>>    length = slprintf(buffer, 32, "%06d", (int) floor(t->f * 1000000));
>> #endif
>>    break;
>>
>>
>> >
>> > On Sat, Sep 27, 2008 at 1:40 AM, Alexey Zakhlestin <indeyets@gmail.com>
>> > wrote:
>> >>
>> >> On Sat, Sep 27, 2008 at 11:04 AM, Ilia Cheishvili
>> >> <ilia.cheishvili@gmail.com> wrote:
>> >> > Hi all,
>> >> > This patch addresses the issue with the date() function.  When
>> >> > passing
>> >> > in a
>> >> > 'u', the date() function simply outputs six zeros.  To fix this, I
>> >> > added
>> >> > a
>> >> > gettimeofday() call that figures out what to display for
>> >> > microseconds.
>> >> >  I am
>> >> > including the headers and using the function with pre-processor
>> >> > safeguards
>> >> > as well.
>> >> > Take a look :)
>> >>
>> >> Wouldn't it be better, to make gettimeofday() call only in case of 'u'?
>> >>
>> >>
>> >> --
>> >> Alexey Zakhlestin
>> >> http://blog.milkfarmsoft.com/
>> >
>> >
>>
>>
>>
>> --
>> Alexey Zakhlestin
>> http://blog.milkfarmsoft.com/
>
>



--

------=_Part_21831_4884611.1222549508848-- ------=_Part_21830_24067706.1222549508848 Content-Type: text/plain; name=date-u-fix-diff.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_flmqdxi10 Content-Disposition: attachment; filename=date-u-fix-diff.txt SW5kZXg6IHBocF9kYXRlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG9zaXRvcnkvcGhwLXNy Yy9leHQvZGF0ZS9waHBfZGF0ZS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjQzLjIuNDUuMi41 MS4yLjU0CmRpZmYgLXUgLWIgLXIxLjQzLjIuNDUuMi41MS4yLjU0IHBocF9kYXRlLmMKLS0tIHBo cF9kYXRlLmMJOCBBdWcgMjAwOCAyMjowNzowNyAtMDAwMAkxLjQzLjIuNDUuMi41MS4yLjU0Cisr KyBwaHBfZGF0ZS5jCTI3IFNlcCAyMDA4IDIxOjAwOjQ5IC0wMDAwCkBAIC0xMTUwLDcgKzExNTAs NyBAQAogCQkJY2FzZSAnSCc6IGxlbmd0aCA9IHNscHJpbnRmKGJ1ZmZlciwgMzIsICIlMDJkIiwg KGludCkgdC0+aCk7IGJyZWFrOwogCQkJY2FzZSAnaSc6IGxlbmd0aCA9IHNscHJpbnRmKGJ1ZmZl ciwgMzIsICIlMDJkIiwgKGludCkgdC0+aSk7IGJyZWFrOwogCQkJY2FzZSAncyc6IGxlbmd0aCA9 IHNscHJpbnRmKGJ1ZmZlciwgMzIsICIlMDJkIiwgKGludCkgdC0+cyk7IGJyZWFrOwotCQkJY2Fz ZSAndSc6IGxlbmd0aCA9IHNscHJpbnRmKGJ1ZmZlciwgMzIsICIlMDZkIiwgKGludCkgZmxvb3Io dC0+ZiAqIDEwMDAwMDApKTsgYnJlYWs7CisJCQljYXNlICd1JzogbGVuZ3RoID0gc2xwcmludGYo YnVmZmVyLCAzMiwgIiUwNmQiLCAoaW50KSB0LT5mKTsgYnJlYWs7CiAKIAkJCS8qIHRpbWV6b25l ICovCiAJCQljYXNlICdJJzogbGVuZ3RoID0gc2xwcmludGYoYnVmZmVyLCAzMiwgIiVkIiwgbG9j YWx0aW1lID8gb2Zmc2V0LT5pc19kc3QgOiAwKTsgYnJlYWs7CkluZGV4OiBsaWIvdW5peHRpbWUy dG0uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvcmVwb3NpdG9yeS9waHAtc3JjL2V4dC9kYXRlL2xp Yi91bml4dGltZTJ0bS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEyLjIuNC4yLjMuMi4yCmRp ZmYgLXUgLWIgLXIxLjEyLjIuNC4yLjMuMi4yIHVuaXh0aW1lMnRtLmMKLS0tIGxpYi91bml4dGlt ZTJ0bS5jCTcgQXByIDIwMDggMTc6NDQ6MDMgLTAwMDAJMS4xMi4yLjQuMi4zLjIuMgorKysgbGli L3VuaXh0aW1lMnRtLmMJMjcgU2VwIDIwMDggMjE6MDA6NDkgLTAwMDAKQEAgLTMyLDYgKzMyLDE1 IEBACiAjaW5jbHVkZSA8c3RyaW5ncy5oPgogI2VuZGlmCiAKKyNpZmRlZiBQSFBfV0lOMzIKKyNp bmNsdWRlICJ3aW4zMi90aW1lLmgiCisjZWxpZiBkZWZpbmVkKE5FVFdBUkUpCisjaW5jbHVkZSA8 c3lzL3RpbWV2YWwuaD4KKyNpbmNsdWRlIDxzeXMvdGltZS5oPgorI2Vsc2UKKyNpbmNsdWRlIDxz eXMvdGltZS5oPgorI2VuZGlmCisKIHN0YXRpYyBpbnQgbW9udGhfdGFiX2xlYXBbMTJdID0geyAt MSwgMzAsIDU5LCA5MCwgMTIwLCAxNTEsIDE4MSwgMjEyLCAyNDMsIDI3MywgMzA0LCAzMzQgfTsK IHN0YXRpYyBpbnQgbW9udGhfdGFiWzEyXSA9ICAgICAgeyAwLCAzMSwgNTksIDkwLCAxMjAsIDE1 MSwgMTgxLCAyMTIsIDI0MywgMjczLCAzMDQsIDMzNCB9OwogCkBAIC00NCw2ICs1Myw4IEBACiAJ dGltZWxpYl9zbGwgaTsKIAl0aW1lbGliX3NsbCBob3VycywgbWludXRlcywgc2Vjb25kczsKIAlp bnQgKm1vbnRoczsKKwlzdHJ1Y3QgdGltZXZhbCB0cCA9IHswfTsKKwlzdHJ1Y3QgdGltZXpvbmUg dHogPSB7MH07CiAKIAlkYXlzID0gdHMgLyBTRUNTX1BFUl9EQVk7CiAJcmVtYWluZGVyID0gdHMg LSAoZGF5cyAqIFNFQ1NfUEVSX0RBWSk7CkBAIC0xMjYsNiArMTM3LDExIEBACiAJdG0tPnNzZV91 cHRvZGF0ZSA9IDE7CiAJdG0tPnRpbV91cHRvZGF0ZSA9IDE7CiAJdG0tPmlzX2xvY2FsdGltZSA9 IDA7CisgCisjaWZkZWYgSEFWRV9HRVRUSU1FT0ZEQVkKKwlnZXR0aW1lb2ZkYXkoJnRwLCAmdHop OworCXRtLT5mID0gdHAudHZfdXNlYzsKKyNlbmRpZgogfQogCiB2b2lkIHRpbWVsaWJfdXBkYXRl X2Zyb21fc3NlKHRpbWVsaWJfdGltZSAqdG0pCg== ------=_Part_21830_24067706.1222549508848--