Project

General

Profile

Actions

Feature #16735

closed

Negative Timestamps

Added by Michael Fritz over 17 years ago. Updated almost 16 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2006-11-24
Due date:
% Done:

0%

Estimated time:
PHP Version:
4.3
Tags:
Complexity:
Sprint Focus:

Description

I cannot assign negative timestamps to the date field. E.g birthdays before 1.1.1970 doesnt work.

Can be fixed inside the js-file:
typo3/jsfunc.evalfield.js

//if ((year>=0&&year<38) || (year>=70&&year<100) || (year>=1970&&year<2038)) {
if ((year>=0&&year<38) || (year>=70&&year<100) || (year>=1902&&year<2038)) {

and

if (this.lastDate<0) {this.lastDate=0;}
//if (this.lastDate<0) {this.lastDate=0
(issue imported from #M4553)


Files

negativetimestamps.patch (29.1 KB) negativetimestamps.patch Administrator Admin, 2007-09-17 19:02
jsfunc.evalfield.js (14.2 KB) jsfunc.evalfield.js Administrator Admin, 2007-09-17 19:06
20080216_negative_timestamps.diff (1.33 KB) 20080216_negative_timestamps.diff Administrator Admin, 2008-02-16 18:33
Actions #1

Updated by Ingo Renner over 16 years ago

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

Actions #2

Updated by Clemens Riccabona over 16 years ago

@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 ...

Actions #3

Updated by Martin Kutschker over 16 years ago

@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.

Actions #4

Updated by Ingo Renner over 16 years ago

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

Actions #5

Updated by Clemens Riccabona over 16 years ago

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!

Actions #6

Updated by Michael Fritz over 16 years ago

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

Actions #7

Updated by Ingo Renner over 16 years ago

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

Actions #8

Updated by Martin Kutschker over 16 years ago

@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().

Actions #9

Updated by Michael Fritz over 16 years ago

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

Actions #10

Updated by Clemens Riccabona over 16 years ago

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.

Actions #11

Updated by Martin Kutschker over 16 years ago

@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. ;-)

Actions #12

Updated by Benni Mack about 16 years ago

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.

Actions #13

Updated by Steffen Kamper about 16 years ago

i created a patch for 4.2 branch and attached it.

Actions #14

Updated by Ingmar Schlecht about 16 years ago

FYI: Committed to TYPO3_4-2, revision 3248.

Actions

Also available in: Atom PDF