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

[Ernesto Baschny [cron IT]]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-8746-timezone.diff
Type: text/x-diff
Size: 4325 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20081229/c81668b8/attachment.diff