[TYPO3-core] Patch: Fix Timezone date problems

[Bernhard Kraft]

Karsten Dambekalns wrote:

> So if we just use date(), mktime() etc. this *may* fail. But anyway, this is 
> good enough. If we needed dates after 2038, we'd still need to include 
> something like ADOdb time library, but...

I would be interested what

<?php
print_r(getdate(-2147483647));
?>

outputs on a windows machine (i have no windows machine running T3 :) of course i
should set some qemu/vmware up to have a testing environment ... :(

But I would say you shouldn't care to much about 2038 if you make the right choice
in 2006/07 :) meaning: Buy a 64-bit Server machine and run a native 64-bit OS :

-----------------------------------
kraftb at oxygen:~$ cat /proc/cpuinfo | grep grep "model name"
model name      : AMD Athlon(tm) 64 Processor 3500+
kraftb at oxygen:~$ php
<?php
print_r(getdate(42949672950000));
?>
Array
(
     [seconds] => 0
     [minutes] => 20
     [hours] => 5
     [mday] => 15
     [wday] => 3
     [mon] => 12
     [year] => 1362990
     [yday] => 348
     [weekday] => Wednesday
     [month] => December
     [0] => 42949672950000
)
------------------------------------

So at least till year 1 million 362 thousand and 990 there will be no obvious problems :)

of course this also works with neagtive timestamps.

It struck me I found out right now that

getdate((2^63)-1));

results in an error:
Warning: getdate(): Cannot perform date calculation in - on line 2

So a 64-bit machine timestamp seems not to have 64 bits but less .. i tested about 32+13 bits above
(x10000 ~ 13.5 bit)

> Now to the patch. This call intval() twice, why not add else?
>  ---- snip ----
> if ($GLOBALS['TYPO3_CONF_VARS']['SYS']['respectTimeZones'] && 
> intval($value))   {
> 	$value = t3lib_div::timestamp_GMT2local(intval($value));
> }
> $value = intval($value);
>  ---- snip ----

will do that.

> Since I didn't test it, no +1, but I like the idea.

I even dreamt in different timezones today :) And had a lot of toughts.

I came to the following conclusion:

With my patch you enter a time in EST and the exactly same value will get displayed on the server as CET.
You would want this behaviour if you input a birthday for example ...
(Notice: You have your birthday twice a year ! Mine is on 20.10. fozr example. 8:3? CET to be more exact. Now
I also have birthday on 19.10. 22:3? or about that in Hawaian timezone for example ... meaning I have
birthday on 19 and 20 of every year !)

Without my patch you input in your local timezone and the server shows the "meaning" of this point of time
in his local zone.
You would want this behavour if you input News for example. Then the real issuing date of the News must get
displayed. You also "think" in your local timezone so in most cases you would want to input dates with your zone
offset.
But now it can happen that you are traveling and set your PC to another timezone so the clock runs correct but
you have to enter News which you shall enter with your home timezone.

The solutions I could offer would be:

A:
Have another "TCA" field eval type "zonedatetime" (or a "zone" => default_val TCA key) which has a select box in
front of the date input field in which the BE editor can select the timezone of the value he enters. when he
already has entered one and switches the zone the value get's converted to the equal point of time in the other timezone.

B:
Have a BE-User setup field in the BE-User configuration "Timezone" which can get set to a timezone. When the User
chooses a date he inputs dates/times using this timezone.
* This can get combined with A. The setting in the BE-User setup (B) would be the default of A

C:
A TCA Setting 'timezone' => 'EST', which set's the timezone in which a field is entered to a value fixed by TCA. As dates
always get stored as seen from the timezone of the server (we can't change this - It was like that before and we need to
be downwards comp.) such a option (C) is almost mandatory for inputing birth-dates (the original bug described 20-10-1980
jumping back to 19-10-1980)


And another fix which is required concerns the FE.

You have no option to define for which timezone a date is outputted using date or strftime. If your server is located in
America for example but you and all your customers are in Europe and you also have a Europe domainname - the server is
located in .us for unknown reasons - then you will always output a time as it was one of the US timezones - becasuse the
server is set to that.

The option [SYS][serverTimeZone] is a good beginning but it must not be set to a value (as +200 can be either EET or CET DST)
but to the "name" of the zone. i will code a function calculating the zone offset for a given date and zone to GMT.

The final solution should be to have an TS option like
config.timezone = SST

which defines in which timezone strftime and date work in the FE.



greets,
Bernhard