Bug #79448

Epic #77562: Misbehaviors with datetime values and timezones

Handling dates in the very past inside T3-Backend

Added by Ralle Büchnitz over 2 years ago. Updated over 1 year ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2017-01-24
Due date:
% Done:

0%

TYPO3 Version:
7
PHP Version:
7.0
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

I tried to store a date around 01.01.1800 in T3-Backend.

I wrote an extension but saving fails each time - as the date is not stored correctly.

I can't even say how T3 determines/converts the date. As the system stores something around 1936. Seems like some sort of converting error in T3-Backend. Same with dates in the very future.

If i set the 'date' field directly in the database to the correct date it won't be displayed at all.

Here are some additional informations:

\ext_tables.sql
geboren_am date DEFAULT '0000-00-00',

Configuration\TCA\mymodel.php
'geboren_am' => array(
'exclude' => 1,
'label' => geboren_am',
'config' => array(
'dbType' => 'date',
'type' => 'input',
'size' => 13,
'max' => 20,
'eval' => 'date',
'checkbox' => 0,
'default' => '0000-00-00'
),
),


Related issues

Related to TYPO3 Core - Bug #69287: Can't enter years before 1902 in date-fields Closed 2015-08-24
Related to TYPO3 Core - Bug #37244: TCA date evaluation for dates lower 01-01-1970 fails Accepted 2012-05-17

History

#1 Updated by Ralle Büchnitz over 2 years ago

Any news on this issue?

#2 Updated by Riccardo De Contardi over 2 years ago

  • Category set to FormEngine aka TCEforms

I add here the comment from #69287 to keep track of it:

To describe the problem a bit more:

the 1970-Problem with dates usually is JavaScript-related.
The datepicker from ExtJS (implemented in TYPO3, at least 6.2) can handle dates back to year 0.
MySQL-datetime can handle dates starting with year 1000. This general option was implemented by Xavier already.
The Datetime-functions of AdoDB can handle years back to year 0, with adjustments probably further back too.
Some databases can handle dates that go further back than 0, i.e. PgSQL can handle approximative -4500
Some PHP-Functions might limit the handling of dates too.
So the problem involves JavaScript, Database and PHP depending on how far you want to be able to go back.
I think a really cool approach would be to enable TYPO3 to take dates older than 0.
I planned working on it but never found the time yet and in the moment I never see any time-window in nearer future.

#3 Updated by Mona Muzaffar over 2 years ago

  • Related to Epic #80852: Datetime handling in backend added

#4 Updated by David Bruchmann over 2 years ago

To understand what's happening it might be helpful to know the history how the current date-handling was first created:
http://xavier.perseguers.ch/en/tutorials/typo3/articles/native-date-type.html

It might be completely different now especially because of refactoring inside TYPO3.

#5 Updated by Christian Fries about 2 years ago

This problem still exists in TYPO3 8. And on top of that: If you try to save an empty date (empty field), you get an error:

1: These fields of record 2 in table "tx_extensionname_domain_model_person" have not been saved correctly: date_of_birth! The values might have changed due to type casting of the database.

#6 Updated by David Bruchmann about 2 years ago

Christian,

I dare to say, the error is an issue with your extension. Probably it can be fixed by changes in database or TCA.
Have a look at the definitions in \ext_tables.sql and Configuration\TCA\mymodel.php above posted by Ralle Büchnitz, especially at 'default' and "geboren_am date DEFAULT '0000-00-00'".

#7 Updated by Christian Fries about 2 years ago

Hi David, I dare to say that's not true. The exact above configuration will not allow you to save a record (form engine, not extbase) with an empty "geboren_am" field in TYPO3 8.7.1.
If you don't belive me, check out the well known extension styleguide. When you try to save the demo record with no date in inputdatetime_2 (which has the same configuration we talk about here, see TCA and sql), you'll get the same error I get in my extension.

#8 Updated by Christoph Bessei about 2 years ago

I can confirm the problem of Christian.
Saving an empty date gives always the "The values might have changed due to type casting of the database." error.

It looks like the problem is some value casting, at least InputDateTimeElement.php always has $itemValue set to 0 instead of '0000-00-00' (which explains the error message).

#9 Updated by Riccardo De Contardi about 2 years ago

  • Parent task set to #77562

#10 Updated by Riccardo De Contardi about 2 years ago

  • Related to deleted (Epic #80852: Datetime handling in backend)

#11 Updated by Christian Fries about 2 years ago

Couldn't be reproduced in current master anymore.

#12 Updated by Riccardo De Contardi over 1 year ago

I think it is still present in 8.7.9 - It is not possible to save a date prior to 01-01-1970 for example in the "start date" of fe_users. The error is still:

1: These fields of record 1 in table "fe_users" have not been saved correctly: starttime! The values might have changed due to type casting of the database.

Also available in: Atom PDF