TYPO3 Core

please provide a patch if you mark the report as having one

@ingo

In my Opinion is there no php version dependency???

Just a javascript, and probably a mysql problem (2nd only if db fields for datetime have been set to unsigned int ...).
So be careful using the patch above without in-depth knowledge!

And the patch above is working properly in most cases. So it HAS patch ...

@clemens

There was a PHP dependency. The docs says that 4.x (on Windows?) had troubles with negative timestamps. But according to th docs this has been resolved. If so we can enable negative timestamps and have dates earlier than 1970.

didn't realize I set a version dependency, but anyways... +1 for negetive timestamps

OK, the problem with php4 in connection with windows is right, but where did you find the solution for that problem?

http://bugs.php.net/bug.php?id=22017

It seems not to be a php4 problem, but a Win32 problem.

And I don't think that it can be fixed. Only the 'Unexpected Error' Messages is more descriptive. Nice but useless. ;)

Quote: "The error is more descriptive now. The cause for this problem is that
you are trying to generate a date string based on a timestamp earlier
then Jan 1 1970, which something that is not supported by Win32."

If there IS REALLY a solution on the php4/Win32 bug/missing feature, it would be nice to know ...

Also interesting: http://at.php.net/manual/en/function.mktime.php

However, with php 5.1.x this problem should be resolved, with php4 ond win it seems to remain forever!

i didn't recognise it as a win bug since im having a linux server. the javascript cuts down all dates before 1970 with this condition, and so i fixed it myself. i my perspective it is still as simple as i described.

and finaly i found a function in svn tortoise to create a patch...

its the file: t3lib\jsfunc.evalfield.js

ps: i can still see this bug with php5

negative timestamp were not possible with php4, but are with php5. thus TYPO3 limited the input to dates after 1970 via JS....

BTW: did you check your patch? If you had, you'd have noticed something ;-)

- not quite usefull

@clemesn

There is no solution for PHP4, bus as TYPO3 4.2 will rquire PHP 5.1 I think this note is good news (though I didn't test it):

"The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer). However, before PHP 5.1.0 this range was limited from 01-01-1970 to 19-01-2038 on some systems (e.g. Windows). "

To be found in the PHP 5.1.0 changelog entry for date().

if the integer field is an unsigned integer, it has to be changed. for me it works perfectly.

in my opinion this is a serious bug which would have made the system useless to my client.

--and i experienced some snottyness over here, not only once..bye

Just to say it again clearly and loud enough so everybody can hear it:

The main problem is, that we store datetime as unix timestamps, which will always have limitations. An integer value never would be infinite!

As I pointed out this problem years ago on my webpage, we should think about the possibility to store datetime values as floating points.

There are no more disadvantages concerning perfomance on nowadays processor architectures (which has been the historical cause for using int values for datetimes in lots of applications) as they can calculate it also in one step!

http://www.riccabona.info/webdesign/typo3-enterprise-cms/typo3-extensions/date-time-problem.html
(Scroll down to 'Fazit' where my suggestions are.)

Sorry, the link is just in German, but if there are enough interests, I would translate it to English too.

@Clemens

I don't see how a float will solve any problems (mind the precision), but feel free submit a feature request for such a scheme (including a description how this should work!). Please don't hijack this bug.

Sdenote: Probably PHP6 will have a new date format and future TYPO3 will make use of it. In the meantime 2038 is fine for most use cases. I'll start worrying around 2020. ;-)

Hey,

can somebody make a patch against the latest 4.2 and send it to the core list? This patch sounds very useful to me. I'd like to see this in 4.2.

i created a patch for 4.2 branch and attached it.

FYI: Committed to TYPO3_4-2, revision 3248.