Bug #63482
openEpic #77562: Misbehaviors with datetime values and timezones
Query constraint on a DateTime field with a DateTime argument should trigger date format
0%
Description
Hi,
I have a DateTime declared like this in TCA :
'dbType' => 'datetime', 'type' => 'input', 'size' => 12, 'eval' => 'datetime,required', 'checkbox' => 0, 'default' => '0000-00-00 00:00:00'
The SQL field is a native DateTime field (created from extension_builder).
When I apply a constraint on a query with an argument, It is automatically converted to an unix timestamp. My query doesn't works because it's expecting a native SQL datetime value instead of a timestamp. The workaround is to apply a format ->format("Y-m-d G:i:s")
on the argument. This is ok but when you have to manipulate many datetime fields or have many queries, the human error factor is increasing.
I don't have digged enough inside the extbase query API to see if we have access to the field type at the moment when the query is build. But It could be great to see this API to take in charge the date formatting step.
I think that this change is a breaking change for all of those who already applied manually the format. It will require a setting to enable/disable this behaviour and by default , It will be disabled.
Updated by Georg Ringer almost 10 years ago
- Tracker changed from Feature to Bug
- TYPO3 Version set to 6.2
- Is Regression set to No
Updated by Benjamin Rau almost 10 years ago
I can confirm the issue! And the workaround would make it impossible to change the dbtype later without changing all constraints..
Updated by Felix Nagel almost 9 years ago
Same issue when using dbType => date in TYPO3 7.6.2
Updated by Stefan Froemken about 8 years ago
- TYPO3 Version changed from 6.2 to 7
- Complexity set to medium
I currently have the same problem, but I don't see any chance to solve that with 2 or 3 lines of code.
I slightly see a possibility to change preparseComparison(). We can add $query or $source as third parameter, but IMO changing DateTime objects at that point is the wrong way.
A better place would be resolveParameterPlaceholders(), but at that point we don't have any information about colnames and classnames anymore. We need them to build a columnMap, which is currently not possible. To solve that we have to change many methodcalls and it seems more breaking than solving that problem.
I can confirm this problem for TYPO3 7.6, too.
Updated by Mona Muzaffar over 7 years ago
- Related to Epic #80852: Datetime handling in backend added
Updated by Riccardo De Contardi over 7 years ago
- Related to deleted (Epic #80852: Datetime handling in backend)
Updated by Georg Ringer almost 7 years ago
- Related to Bug #79473: Typo3DbQueryParser fails since Doctrine by comparing date fields added
Updated by Felix Nagel about 2 years ago
Still an issue in TYPO3 11.5.16 when using dbType => date.