Bug #16893
closed
timezone-problem
0%
Description
THE PROBLEM
If you enter date/time in BE the calculation of the timestamp is done by javascript (evaldate).
This javascript is executed from the client browser and uses the timezone of the client (user).
This calculated timestamp has the users offset and is a relative value and not absolute (GMT 0), so it is impossible
to decide later from which timezone this value is entered.
This causes problems, which i want to show by example:
- user creates record and client is GMT 0 : timestamp is created with GMT 0
- user creates record and client is GMT -8 : timestamp is created with GMT -8
When the record is displayed, the server is calculating the date value from timestamp, and the server uses the timezone of the server.
If user and server are in the same timezone, the displayed value is the same as entered, if the timezones are different, the displayed value is different to the entered value.
CASE 1:
Server is in germany GMT +1
BE-User is in the USA GMT -8 und and edit a record:
A Newsrecord should be started 20.02.2007, 9:00 am
Typo3 calculates startdate with GMT1: 18:00 (6:00 pm).
The user in USA has no possibilities to enter his wanted startdate 9:00 am (GMT +1), he has to recalculate manually.
CASE 2:
An installation has to be moved from server (germany) to a new server (USA).
After restoring DB on the new server all date entries are displayed wrong cause they are calculated now with the new server timezone.
REMARK:
$TYPO3_CONF_VARS['SYS']['serverTimeZone'] is never used in Core and doesn't help anyway, cause server calculates dates with php and server timezone.
NEXT PROBLEM:
we have an event in future (summertime), we are now in wintertime. Calculation of the Event date is wrong, complex recalculation is needed.
IDEAS FOR SOLVING:
- for every timestamp in DB an extrafield is needed with the GMZ-offset, timestamp is saved without offset (GMT 0)
so recalculating of date is easy with offsetfield
Displaying the date has following possibilities:
- with users timezone (timestamp + offset)
- with server timezone (timestamp + server offset)
this has great options included, like every event can be displayed with timezone of the client, or shown as absolute showing the timezone too.
BE- and FE-User should have stored infos of their timezone, if they are set, calculation can be automatic.
(issue imported from #M4849)
Updated by Steffen Kamper about 17 years ago
I'm wondering that here is no reaction, cause I heard from several people struggling with this problem.
In the podcast with Georg Kuhnberger he also told about this problem and mentioned, that they allready have a solution for that, but I got no response. While developing calendar base this is one main problem, cause there are a lot of timestamps handled and more often people from different timezones edit the events. So a solution of this problem is very essential.
I also know from Bernhard that he started a solution.
Because this circumstances i didn't developed a solution to prevent double work, so please give some feedback.
Updated by Ernesto Baschny about 17 years ago
Please see bug #15133 which has a pending solution which will be soon integrated into the core. It would be cool if other people could give some feedback if the attached patch there solves the problem.
Updated by Ernesto Baschny about 17 years ago
Thanks for the report, Steffen. I will close this just so that we can continue discussion about it in the bug marked as "duplicate" to this one. The solution I present there is similar to what you suggest, but is a bit more backwards compatible: We don't store the UTC time in the database, but the timestamp for the timezone the server lives in. This is how it always have been so that most TYPO3 databases already contain all those kind of timestamps.
So the solution is just to use the UTC timestamp as the standarized way that the client communicates a date time information to the server, which will convert that back to the servers timezone. So in the forms, we will always have UTC timestamps, but in the database still server-based timestamps.
The solution also takes into account DST, because the calculation will always go back to UTC, which is independant of DST.