TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692022-07-28T11:47:54ZTYPO3 Forge
Redmine TYPO3 Core - Bug #98045 (Under Review): DateAspect->getTimezone (almost) never returns the correc...http://forge.typo3.org/issues/980452022-07-28T11:47:54ZJan Deliusme@jandelius.eu
<p>On the way the DateTimeAspect is initiated, there is never an evaluation of the current time zone. Thus the aspect always returns only the time zone "+00:00". Also the ISO date is always given in UTC instead of the currently set server time zone.</p>
<p>An example of this is given in the method TYPO3\CMS\Frontend\Http\Application::initializeContext():<br /><pre><code class="php syntaxhl" data-language="php"><span class="nv">$this</span><span class="o">-></span><span class="n">context</span><span class="o">-></span><span class="nf">setAspect</span><span class="p">(</span><span class="s1">'date'</span><span class="p">,</span> <span class="k">new</span> <span class="nc">DateTimeAspect</span><span class="p">(</span><span class="k">new</span> <span class="nc">\DateTimeImmutable</span><span class="p">(</span><span class="s1">'@'</span> <span class="mf">.</span> <span class="nv">$GLOBALS</span><span class="p">[</span><span class="s1">'EXEC_TIME'</span><span class="p">])));</span>
</code></pre></p>
<p>A proof-of-concept code that makes the aspect return the correct values:<br /><pre><code class="php syntaxhl" data-language="php"><span class="nv">$dateTime</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">\DateTime</span><span class="p">(</span><span class="s1">'@'</span> <span class="mf">.</span> <span class="nv">$GLOBALS</span><span class="p">[</span><span class="s1">'EXEC_TIME'</span><span class="p">]);</span>
<span class="nv">$dateTime</span><span class="o">-></span><span class="nf">setTimezone</span><span class="p">(</span><span class="k">new</span> <span class="nc">\DateTimeZone</span><span class="p">(</span><span class="nb">date_default_timezone_get</span><span class="p">()));</span>
<span class="nv">$this</span><span class="o">-></span><span class="n">context</span><span class="o">-></span><span class="nf">setAspect</span><span class="p">(</span><span class="s1">'date'</span><span class="p">,</span> <span class="k">new</span> <span class="nc">DateTimeAspect</span><span class="p">(</span><span class="nc">\DateTimeImmutable</span><span class="o">::</span><span class="nf">createFromMutable</span><span class="p">(</span><span class="nv">$dateTime</span><span class="p">)));</span>
</code></pre></p>
<p>This aspect is created in several places in the TYPO3 core. The value of <code>date_default_timezone_get()</code> is already defined beforehand by TYPO3 (if required) and should thus be able to be taken.</p>
<p>Apparently this bug has been present since the existence of the aspects until the current branch of the 12 version.</p> TYPO3 Core - Feature #87551 (New): Explicitly allow ignoring "pidInList" in TS select functionhttp://forge.typo3.org/issues/875512019-01-25T15:59:15ZAndreas Wolfandreas.wolf@typo3.org
<p>Currently, the implementation of the TypoScript function "select" will automatically set "pidInList" to "this" if it is not set, even when "uidInList" is specified and points to a uid on a different page.<br />The result will then be empty, even if the record exists and could be displayed. This is confusing and hard to understand, especially since there is no documented way of ignoring "pidInList". Instead, some people implement workarounds with high recursion limits e.g. descending from the site's root page.</p>
<p>My proposal is to add a new setting "ignore" that will lead to the value not being evaluated. This works already, since the non-empty value will prevent the default of "this" from being used. However, it is undocumented behaviour and thus might break in the future w/o any notice. Therefore, let's make it explicit and document it.</p> TYPO3 Core - Bug #68651 (Accepted): Datetime() properties have wrong timezonehttp://forge.typo3.org/issues/686512015-07-30T21:02:27ZMartin Blessmartin.bless@mbless.de
<p><strong>Summary:</strong></p>
<p>The TYPO3 backend does it right. Would be great to have Extbase doing right as well!</p>
<p><strong>Details:</strong></p>
<p>My timezone is set to "Europe/Berlin" ('phpTimeZone' => 'Europe/Berlin')</p>
<p>In the backend everything is ok: I can enter "31-10-2015 00:00" in a field 'firstDay' and it's always correct. But in the frontend, with Extbase/Fluid and <br /><pre>
<f:format.date format="d.m.Y">{offer.firstDay}</f:format.date>`
</pre></p>
<p>I will see "30.10.2015" as output, because that date has been calculated for timezone GMT/UTC, which is "30-10-2015 22:00" which is 2 hours less than our current CEST (central european summer time).</p>
<p>The problem is, that Extbase instantiates the offer.firstDay DateTime() object with timezone_type => 1:</p>
<pre>
object(DateTime)[1]
public 'date' => string '2015-10-30 22:00:00' (length=19)
public 'timezone_type' => int 1
public 'timezone' => string '+00:00' (length=6)
</pre>
<p>while it actually needs the correct timezone information.</p>
<p>I can correct that in the following manner:</p>
<pre>
// we use $now to copy the timezone from
$now = new \DateTime();
firstDay->setTimeZone($now->getTimezone());
</pre>
<p>After that procedure var_dump($firstDay) says:</p>
<pre>
object(DateTime)[1]
public 'date' => string '2015-10-31 00:00:00' (length=19)
public 'timezone_type' => int 3
public 'timezone' => string 'Europe/Berlin' (length=13)
</pre>
<p>And now $firstDay will give the same result that the backend gives for<br /><pre>
<f:format.date format="d.m.Y">{offer.firstDay}</f:format.date>`
</pre></p>
<p>The result is now the expected "31.10.2015".</p>
<p><strong>Earlier discussions</strong></p>
<p>When searching for a solution I found an earlier discussion of that issue here: <a class="external" href="http://lists.typo3.org/pipermail/typo3-project-typo3v4mvc/2010-July/006013.html">http://lists.typo3.org/pipermail/typo3-project-typo3v4mvc/2010-July/006013.html</a></p>