TYPO3 Core

as far as i can remeber, that feature works nearly as expected.

There is only one Bug:

there must be an global variable which holds "now()"

and now() is updated everytime you add and value into that field.

test that:

enter +1 to date field
go to another field,
clear value of date field and enter +1

you will get an +2 :)
and so on.

the example above:
+1: add 3 days
+2: add 2 days
+3: add 6 days

would has been done in that order:
+2: add 2 days
+1: add 3 days
+3: add 6 days

ok?

sorry, but i did not find the javascript which is responsible:/

regards,
martin

it belongs to

this.lastDate in function evalFunc_input(type,inVal)

in file /t3lib/jsfunc.evalfield.js

this.lastDate += add*24*60*60;

if you enter "+2"
this.lastDate += 2*24*60*60 will be calulated.
but this.lastDate will not set back to current time.

but i do not know (now?) whats the correct way to fix it

for case "date":

case "+":
case "-":
if (values.valPol¹) {
add = this.pol(values.valPol¹,this.parseInt(values.values¹));
}
this.lastDate = this.getTimestamp(today);
var theTime = new Date();
theTime.setTime((this.lastDate - theTime.getTimezoneOffset()*60)*1000);
this.lastDate = this.getTimestamp(today);
break;

seems to work

but i am not sure do understand the whole thing - with time and datetime..

so i cannot write an patch atm

ok, i added an patch,

but i did not test it enough

Thanks for the patch, it works fine. I'll post this to the core team list now.

Btw. does anyone know since when this is broken? I remember it worked pretty fine once...

After looking through the code, I will not change it. The issue was introduced in revision 2752 by Ernesto Baschny. It seems like it has to do with the timezone stuff which he fixed, and since he knows the logic best, I would like him to look at this.

Ernesto, can you please have a look at the proposed fix?

Changing target version to 4.2.5 because this won't be ready for 4.2.4.

As far as I can see, the described behaviour is not a bug, as it has always been like that (since 3.8.1, I just tested it).

The fix proposed by Martin would change the behaviour of +XX, and stuff like this won't work anymore: "2008-12-29 +2", which correctly results in "2008-12-31".

The only bugs I found while testing on this matter were:

- "d" is not working as expected once you have had some other date in the field (or any field on that form). I just reported this as #19752.
- the issue #19752 rised by Steffen some time ago (+xx shifting time by clients timezone).

Another issue is that the "+XX", "d", "t", "n" syntaxes allowed in these date(time) fields are not documented anywhere, so it is difficult to know what is intended by the original author (Kasper?) and what is a side-effect of the evaluations made.

This is the intended behaviour (at least it has been like that for ages). So "won't fix".