[TYPO3-core] RFC: #8746+#10033+#9676: Fixes for date/time fields issues (timezone and "d")

[Ernesto Baschny [cron IT]]

Hi,

thanks for the quick review. Commited to trunk (rev. 4628) and TYPO3-4_2
(rev. 4629).

Cheers,
Ernesto


Ernesto Baschny [cron IT] wrote: on 29.12.2008 13:09:
> This is an SVN patch request.
> 
> Type: Bugfix
> 
> Bugtracker references:
> 1) http://bugs.typo3.org/view.php?id=10033 (the "d" issue)
> 2) http://bugs.typo3.org/view.php?id=8746 (the "+xx" timezone issue)
> 3) http://bugs.typo3.org/view.php?id=9676 (which I would close as it is
> not a bug)
> 
> Branches: TYPO3-4_2 and trunk
> 
> Problem(s):
> 
> On TCEmain forms with date/time fields, some client-side handling were
> buggy since 4.2.0:
> 
> 1) typing "d" in a date/time field used to get the current date. This
> now only works for the first time one enters a date in an empty field.
> After that, we instead get the last date entered.
> 
> 2) typing something like "d", "d+0", "d-10", or even just "+0" or "+1"
> on a datetime field and moving focus away we expect the calculated date
> with the current time. Instead we get the time shifted back to UTC (so
> -1 hour if we are at GMT+1).
> 
> 3) minor but very anoying long-standing issue (not related to the
> timezone issues): we couldn't just enter a "date" on a datetime-field.
> After this patch, it is now possible (hour will be "0:00").
> 
> 
> Solution:
> See attached patch. I moved all "client-timeshifting" situations to a
> new function (convertClientTimestampToUTC) so that we only have one
> place where the client's getTimezoneOffset is considered.
> 
> 
> Notes:
> Since TYPO3 4.2 we changed the handling of timezone: client converts to
> UTC before sending form data to server. Server converts from UTC to
> server-timezone before storing into database. This solved a lots of
> issues regarding server standing on different timezones than the client,
> but introduced some minor issues, from which hopefully the last two were
> fixed with this patch.
> 
> 
> How-to-reproduce:
> For your convenience I attached the extension "user_datetest" to
> bug#8746, which only creates a new table with all possible date/time
> fields in it.
> 
> Test the following:
> 1) create empty new record
> 
> 2) enter "d" on the datetime field, move focus away:
>   - expected: today with current time
>   - buggy: today, but with time shifted to UTC
> 
> 3) enter "d" on the date field, move focus away:
>   - expected: today
>   - buggy: if you happen to be on UTC+xx, date will be yesterday!
> 
> 4) enter "d+1" on the datetime field, move focus away:
>   - expected: tomorrow with current time
>   - buggy: tomorrow, but with time shifted to UTC
> 
> 5) enter "d" on the datetime field which already contains some day, move
> focus away:
>   - expected: date and time changed to "today"
>   - buggy: old datetime from field stays, no way to get back to "d"
> 
> 5) create empty new record
> 
> 6) enter "+0" on the datetime field, move focus away:
>   - same results as on step 2)
> 
> 7) enter "13:02 29-1-2008 +2" on the datetime field:
>   - expected is "13:02 31-1-2008". This actually works, but will fail
> with the patch from Martin Holz in bug#9676, so this is just for
> demonstration purposes that it still works after the patch
> 
> 8) enter "29-1-2008" on a datetime field:
>   - expected: "0:00 29-1-2008"
>   - buggy: last date+time we had in the field.
> 
> 
> Now apply the patch and try it out again. Note: As the .js file is
> changed, you need to force your browser to reload them after patching
> (SHIFT-reload on Firefox, CTRL-reload on IE).
> 
> Cheers,
> Ernesto
>