Forums / Developer / Year 2038 problem (also known as "Unix Millennium bug")

Year 2038 problem (also known as "Unix Millennium bug")

Author Message

Donat Fritschy

Friday 27 June 2008 2:32:12 am

eZ stores Dates in UNIX Format, as number of seconds from January 1st, 1970. This severly limits the range of valid dates (http://ez.no/doc/ez_publish/technical_manual/4_0/reference/datatypes/date) to a range of 1.1.1970 to 18.01.2038.

This causes not only problems for novice users (see http://ez.no/developer/forum/developer/attribute_of_type_date), but also poses a bigger problem, known as the Year 2038 problem (also known as "Unix Millennium bug").

http://en.wikipedia.org/wiki/Unix_time
http://en.wikipedia.org/wiki/Year_2038_problem

What are the plans of eZ to address this problem? Mapping the eZ Date datatype to an 64Bit integer would seem rather straightforward to me.

http://www.webmanufaktur.ch - Developers united in eZ Publish: http://www.cjw-network.com

Björn Dieding@xrow.de

Friday 27 June 2008 8:14:32 am

Lets save our planet first! A lot can happen in 30 years.

http://projects.ez.no/birthday

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Piotrek Karaś

Friday 27 June 2008 8:52:07 am

Lets save our planet first! A lot can happen in 30 years.

And how do we do that? ;)

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Björn Dieding@xrow.de

Friday 27 June 2008 8:55:29 am

Offtopic:

http://www.energysavingtrust.org.uk/calculator/start

You could start cutting your co2 emissions.

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Donat Fritschy

Friday 27 June 2008 9:10:19 am

I am, of course, aware of the http://projects.ez.no/birthday extension.

This datatype, however, has different drawbacks:

* it does not handle times
* you can't do any calculations

And, besides, you do not need to wait 30 years before anything happens. So this thread was meant as a serioius topic ;-)

http://www.webmanufaktur.ch - Developers united in eZ Publish: http://www.cjw-network.com

Ole Marius Smestad

Monday 30 June 2008 7:43:57 am

Hi Donat,

The best way of dealing with the issue of dates falling outside of the traditionally supported range 1970 - 2038, is to use the new class DateTime, introduced in PHP 5.2.x.

This allows you to operate on a much larger date range, as large as one would ever need presumably. As the DateTime object works with 64-bit values for the dates internally, this will increase the usable date range, even on a 32-bit system, additionally DateTime handles timezones.

In the upcoming PHP 5.3 there will also be elegant, built-in support in the language for calculating date intervals between such DateTime objects. Will requiring PHP 5.3 when it becomes available, be a problem for you?

As for utilising this new object inside eZ Publish, the best course of action would be to introduce a new datatype which uses DateTime natively. Using a new datatype for this, will allow existing sites to work, and sites could gradually be ported over from older datatypes. Given there is a conversion tool between the datatypes.

As of now there isn't a decision to include such a new datatype in a specific version, but this is up for discussion, before the roadmaps for upcoming maintenance releases are set. The problem of the limited date range is something we are aware of, and would like to offer a remedy for.


--
Ole Marius Smestad
Lead Engineer eZ Publish
Member of the Community Project Board

Björn Dieding@xrow.de

Monday 30 June 2008 11:10:34 am

also need to consider storage... e.g. mysql won`t store it as a int before version 7

http://bugs.mysql.com/bug.php?id=12654
http://forge.mysql.com/worklog/task.php?id=1872 Priority: Low

so far we need to store it as a string representation in the db...

So it will be not alike the current datetime datatype for a long time.

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Donat Fritschy

Tuesday 01 July 2008 1:50:44 am

Yes, Björn!

you make an important point here. The more important it is to create awareness of the problem in order to find and implement the best solution.

Regards,
Donat

http://www.webmanufaktur.ch - Developers united in eZ Publish: http://www.cjw-network.com