[#ZF-4490] Zend_Date::getDate() returns non-zero time part for dates not in UTC - Zend Framework Issue Tracker

Details

Type: Bug
Status: Resolved
Priority: Minor
Resolution: Fixed
Affects Version/s: None
Fix Version/s: 1.7.0
Component/s: Zend_Date
Labels:
None

Description

For Zend_Dates in a timezone other than UTC, getDate() doesn't return a date with 0 time part, as described in docu, but instead 0 + time zone base offset (without DST).

I don't know if this is intended or not. If it is, it should be documented in the documentation.

Example of when this is a problem:
You have a set of objects and want to select only those whose time property is today. So you filter using (time >= Zend_Date::now()- >getDate()->getTimestamp() && time < ...). But this will not display what the user considers "today" (what is today in the current timezone).

Example:

$ php
<?php
require_once 'Zend/Date.php';

date_default_timezone_set('Europe/Ljubljana');
$date = Zend_Date::now();

echo $date.PHP_EOL;
echo $date->getDate().PHP_EOL;
Oct 5, 2008 11:29:00 AM
Oct 5, 2008 1:00:00 AM

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Jaka Jancar added a comment - 05/Oct/08 2:51 AM

Given the docu (Returns a clone of $this, with the time part set to 00:00:00.), I would expect it to work the same as this:

$ php
<?php
require_once 'Zend/Date.php';

date_default_timezone_set('Europe/Ljubljana');
$date = Zend_Date::now();

echo $date.PHP_EOL;

$date->set(0, 'HOUR');
$date->set(0, 'MINUTE');
$date->set(0, 'SECOND');
$date->set(0, 'MILLISECOND');

echo $date.PHP_EOL;
Oct 5, 2008 11:48:53 AM
Oct 5, 2008 12:00:00 AM

Show

Jaka Jancar added a comment - 05/Oct/08 2:51 AM Given the docu (Returns a clone of $this, with the time part set to 00:00:00.), I would expect it to work the same as this:

$ php
<?php
require_once 'Zend/Date.php';

date_default_timezone_set('Europe/Ljubljana');
$date = Zend_Date::now();

echo $date.PHP_EOL;

$date->set(0, 'HOUR');
$date->set(0, 'MINUTE');
$date->set(0, 'SECOND');
$date->set(0, 'MILLISECOND');

echo $date.PHP_EOL;
Oct 5, 2008 11:48:53 AM
Oct 5, 2008 12:00:00 AM

Hide

Permalink

Thomas Weidner added a comment - 10/Nov/08 12:16 PM

Fixed with r12524 in trunk

Show

Thomas Weidner added a comment - 10/Nov/08 12:16 PM Fixed with r12524 in trunk

Hide

Permalink

Wil Sinclair added a comment - 13/Nov/08 2:10 PM

Changing issues in preparation for the 1.7.0 release.

Show

Wil Sinclair added a comment - 13/Nov/08 2:10 PM Changing issues in preparation for the 1.7.0 release.

Hide

Permalink

Lauri Kotilainen added a comment - 09/Aug/09 6:38 AM

Repro in Zend 1.8.1:

<?php
    require_once('Zend/Date.php');
    date_default_timezone_set('Europe/Helsinki');
    $date = Zend_Date::now()->getDate();
    echo $date->toString() . PHP_EOL;

result:

8.8.2009 23.00.00

Show

Lauri Kotilainen added a comment - 09/Aug/09 6:38 AM Repro in Zend 1.8.1:

<?php
    require_once('Zend/Date.php');
    date_default_timezone_set('Europe/Helsinki');
    $date = Zend_Date::now()->getDate();
    echo $date->toString() . PHP_EOL;

result:

8.8.2009 23.00.00

Hide

Permalink

Holger Schletz added a comment - 07/Sep/11 4:01 PM

The bug still persists as of 1.11.10. Precisely, the result of getDate() is 1 hour off when DST is in effect for the given date. For dates without DST or when the timezone is set to UTC/GMT, the result is correct. Example:

date_default_timezone_set('Europe/Berlin');

// DST in effect: result incorrect
$date = new Zend_Date('2010-06-20 14:56:33');
$date = $date->getDate();
echo $date->toString() . PHP_EOL;

// no DST in effect: result correct
$date = new Zend_Date('2010-12-20 14:56:33');
$date = $date->getDate();
echo $date->toString() . PHP_EOL;

Result:

19.06.2010 23:00:00
20.12.2010 00:00:00

The substitute solution with setting the time to midnight works either way. getDate() itself is currently unusable for DST-aware timezones.

The unit test only checks for 2002-01-04 (no DST) and therefore succeeds. A second check with a DST date is required for a full test. Additionally, the checks should be performed with timezone set to both UTC and a DST-aware timezone. The current test appears to use Indian/Maldives, which did NOT show the erratic behavior with my own test script. No DST on the maldives, I suppose. I'd recommend a timezone that is more than 1 hour away from UTC, so that it's clear whether the offset comes from the timezone or from DST.

The inconsistency of this bug's history may result from the use of Zend_Date::now() for testing. The reports come from mid-October and August (DST in effect), while the fix was made in November (no DST, no erratic behavior).

Show

Holger Schletz added a comment - 07/Sep/11 4:01 PM The bug still persists as of 1.11.10. Precisely, the result of getDate() is 1 hour off when DST is in effect for the given date. For dates without DST or when the timezone is set to UTC/GMT, the result is correct. Example:

date_default_timezone_set('Europe/Berlin');

// DST in effect: result incorrect
$date = new Zend_Date('2010-06-20 14:56:33');
$date = $date->getDate();
echo $date->toString() . PHP_EOL;

// no DST in effect: result correct
$date = new Zend_Date('2010-12-20 14:56:33');
$date = $date->getDate();
echo $date->toString() . PHP_EOL;

Result:

19.06.2010 23:00:00
20.12.2010 00:00:00

The substitute solution with setting the time to midnight works either way. getDate() itself is currently unusable for DST-aware timezones. The unit test only checks for 2002-01-04 (no DST) and therefore succeeds. A second check with a DST date is required for a full test. Additionally, the checks should be performed with timezone set to both UTC and a DST-aware timezone. The current test appears to use Indian/Maldives, which did NOT show the erratic behavior with my own test script. No DST on the maldives, I suppose. I'd recommend a timezone that is more than 1 hour away from UTC, so that it's clear whether the offset comes from the timezone or from DST. The inconsistency of this bug's history may result from the use of Zend_Date::now() for testing. The reports come from mid-October and August (DST in effect), while the fix was made in November (no DST, no erratic behavior).

People

Assignee:

Thomas Weidner

Reporter:

Jaka Jancar

Vote (0)

Watch (8)

Dates

Created:

05/Oct/08 2:40 AM

Updated:

07/Sep/11 4:01 PM

Resolved:

10/Nov/08 12:16 PM

Time Tracking

Estimated:

Not Specified

Remaining:

Logged:

30m