Zend_Date API loses 7 hours from 18 Jan 2038 07:14 AM to 19 Jan 2038 02:15 PM

[zfbot]

Jira Information

Original Issue:	ZF-12456
Issue Type:	Bug
Reporter:	Harry Tarnz
Created:	10/28/12
Assignee:	Thomas Weidner
Components:	Zend_Date

Description

7 hours seem to "disappear" (actually, an earlier range of time is repeated) from 18 Jan 2038 07:14 AM to 19 Jan 2038 02:15 PM. We are in time zone Los Angeles, so we are GMT -7 hours, so we think that's where the problem arises. If we switch to time zone GMT, there is no such offset. We theorize (but have not checked) that other time zones may have similar problems.

The result of leaving such a condition in (whether the result of a bug or even by design) could mean the catastrophic failure of some IT systems in 25 years, around January 18-19, 2038. In fact, we have a mission critical system that would have eventually failed with significant consequences had we not tested for and uncovered this situation. (We are currently employing a workaround.)

EXAMPLE

This code:

$d = new Zend_Date('01/18/2038 07:14 PM');
echo $d . '
';
$d = new Zend_Date('01/18/2038 07:15 PM');
echo $d . '
';
$d = new Zend_Date('01/19/2038 02:14 AM');
echo $d . '
';
$d = new Zend_Date('01/19/2038 02:15 AM');
echo $d . '
';

produces this output:

Jan 18, 2038 7:14:00 PM
Jan 18, 2038 12:15:00 PM
Jan 18, 2038 7:14:00 PM
Jan 19, 2038 3:15:00 AM

NOTES:

1. We would expect that any sequence of "$d = new Zend_Date('some date'); echo $d . '
   ';" would produce a result consistent with the input date string.
2. The "Jan 18, 2038 12:15:00 PM" should have been the minute after "7:14:00 PM", or "7:15:00 PM". Instead, it is seven hours earlier.
3. Similarly, the "Jan 18, 2038 7:14:00 PM" should have been the minute before "Jan 19, 2038 3:15:00 PM", or "Jan 19, 2038 3:14:00 PM". Instead, it is seven hours earlier.
4. The time range from "Jan 18, 2038 12:15:00 PM" to the same day at "7:14:00 PM" is repeated twice.
5. The issue probably doesn't occur exactly at seconds = 00, but the minute is the most discrete level of our test.
6. Also, on and after "Jan 19, 2038 3:15:00 AM", the time is now off by +1 hour.

We are currently using Zend Framework 2.3.0.

Thank you for the timesaving Zend and the wonderful Zend Date API. Good luck on the resolution.

[zfbot]

(Originally posted by: Harry Tarnz on 10/28/12)

Corrected intro

[zfbot]

(Originally posted by: akrabat on 11/06/12)

Interestingly, I don't see this output on my system.

I get:

Jan 18, 2038 6:14:00 PM
Jan 18, 2038 6:15:00 PM
Jan 19, 2038 1:14:00 AM
Jan 19, 2038 1:15:00 AM

This feels like it's related to timezone handling somewhere.

[zfbot]

(Originally posted by: akrabat on 11/06/12)

Another data point:

date_default_timezone_set('Etc/GMT-7');
$d = new Zend_Date('01/18/2038 07:14 PM');
echo $d . PHP_EOL;
$d = new Zend_Date('01/18/2038 07:15 PM');
echo $d . PHP_EOL;
$d = new Zend_Date('01/19/2038 02:14 AM');
echo $d . PHP_EOL;
$d = new Zend_Date('01/19/2038 02:15 AM');
echo $d . PHP_EOL;

results in:

Jan 18, 2038 7:14:00 PM
Jan 18, 2038 7:15:00 PM
Jan 19, 2038 2:14:00 AM
Jan 19, 2038 2:15:00 AM

[zfbot]

(Originally posted by: Harry Tarnz on 01/05/13)

We've isolated this issue to 32-bit stacks. 64-bit stacks seem to work fine, probably because the longer work stacks have longer default integer number sizes (i.e., 64-bit as opposed to the smaller 32-bit). One solution, if you see this issue, would be to move from a 32-bit to a 64-bit OS.

[zfbot]

(Originally posted by: froschdesign on 01/06/13)

@Harry
Thank you for the info!

[zfbot]

This issue was ported from the ZF2 Jira Issue Tracker at
http://framework.zend.com/issues/browse/ZF-12456

Known GitHub users mentioned in the original message or comment:
@akrabat, @froschdesign

[froschdesign]

There are 2 options for a solution:

• move from a 32-bit to a 64-bit OS
• using DateTime and IntlDateFormatter (>= PHP 5.3)

Therefore I will close this issue here.