Bug #37244

Epic #77562: Misbehaviors with datetime values and timezones

TCA date evaluation for dates lower 01-01-1970 fails

Added by Tobias Klepp over 7 years ago. Updated about 2 years ago.

Status:
Accepted
Priority:
Should have
Category:
FormEngine aka TCEforms
Target version:
-
Start date:
2012-05-17
Due date:
% Done:

0%

TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
medium
Is Regression:
No
Sprint Focus:

Description

I configured in TCA the birthday in my own extension table as a required date field. If I try to enter a birthday like 10-4-1965 I see always the yellow alert icon and I cant save the record, because the system say, that I must fill out all required fields. The timestamp for dates lower then 01-01-1970 are negative. I think, that's the problem.

This is my TCA configuration:

'birthday' => array (
  'exclude' => 1,
  'label' => 'LLL:EXT:ams_eventmanager/locallang_db.xml:tx_amseventmanager_registrations.birthday',
  'config' => array (
    'type'     => 'input',
    'size'     => '8',
    'max'      => '20',
    'eval'     => 'required,date',
    'checkbox' => '0',
    'default'  => '0',
  )
),

Related issues

Related to TYPO3 Core - Bug #21838: Date field on TCA can't accept 1-1-1970 as Closed 2009-12-10
Related to TYPO3 Core - Feature #61110: Support for timezones in all date fields in TYPO3 BE New 2014-08-21
Related to TYPO3 Core - Bug #53640: js validation for datetime + required doesn't work for below 1970 Closed 2013-11-14
Related to TYPO3 Core - Bug #61952: bug dbType for date before 01-01-1970 Closed 2014-09-29
Related to TYPO3 Core - Bug #69290: Dates get reduced by a day if before 1970 Closed 2015-08-24
Related to TYPO3 Core - Bug #69287: Can't enter years before 1902 in date-fields Closed 2015-08-24
Related to TYPO3 Core - Bug #73871: Problem with date Field Closed 2016-03-02
Related to TYPO3 Core - Bug #79448: Handling dates in the very past inside T3-Backend New 2017-01-24

History

#1 Updated by Steffen Gebert over 7 years ago

  • Target version deleted (4.5.16)

Well, welcome to the Unix world ;-) The date is saved as unix timestamp, which has a value of 0 at 1st of January 1970 (begin of the unix epoch).

I will point Xavier Perseguers to this thread, as i know that he did something like this few days ago - however I'm unsure, if this will be changed in the TYPO3 core.

#2 Updated by Xavier Perseguers over 7 years ago

You're right. The code for "required" makes it wait for a positive value.

But even if removing the required, there's a hard coded limit of 1970 for the ExtJS date picker.

Finally I forgot about this date picker which is not UX friendly anyway for real old dates. I created my own control with 3 select boxes (day, month and year). Old fashioned but much more efficient anyway. A small JS stores it as a timestamp with a few hours offset, this lets me distinguish between 0 = no date and 3600 which rounds to 1.1.1970. In addition I had the requirement of being able to store a date without the year part (for partners...) and the trick is to save it as year 1800 (for instance). I just had to change DB field to bigint to accommodate the large negative value...

I'd happily share my code (which supports required as well) but I'm away with only my iPhone...)

#3 Updated by Susanne Moog over 7 years ago

  • Status changed from New to Accepted
  • Complexity set to medium

#4 Updated by Jigal van Hemert over 7 years ago

Is there a reason to force a "required" "date/datetime/time" field to be a positive value?

I tried the ExtJS date/time picker in 4.7 and it had a few glitches:
  • picking a year somewhere < 100 (haven't tried the exact year) does not show a calendar of that year, but of 19xx
  • using the calendar icon on a year < 1902 makes it open the calendar of this year
  • using the next/prev month arrows you can get calendars far below 100
  • I haven't checked if it handles Gregorian vs. Julian dates, but the Gregorian calendar was adopted by various countries somewhere between 1582 and 1923 (Greece) so it's quite complicated to handle dates in the past
Maybe we can change things in 6.0 a bit:
  • allow dates before 1970
  • have an eval "positive" (an maybe similar) to force positive values for starttime/endtime/etc. which are unsigned integer fields
  • see if we can make the datepicker consistent with what's possible in PHP date handling

#5 Updated by Mathias Schreiber over 4 years ago

  • Assignee set to Mathias Schreiber
  • Target version set to 7.1 (Cleanup)
  • Is Regression set to No

WIP

#6 Updated by Benni Mack about 4 years ago

  • Target version changed from 7.1 (Cleanup) to 7.4 (Backend)

#7 Updated by Susanne Moog about 4 years ago

  • Target version changed from 7.4 (Backend) to 7.5

#8 Updated by Sebastian Schmal almost 4 years ago

the same problem in T3 6.2.15

1902 is the last date that works
1901 jump on 2015

:(

#9 Updated by Benni Mack almost 4 years ago

  • Target version changed from 7.5 to 7 LTS

#10 Updated by Mathias Schreiber almost 4 years ago

  • Target version deleted (7 LTS)

#11 Updated by Mario Lubenka about 3 years ago

#21838 was closed as duplicate of this ticket, that's why I'm commenting here...

The problem described in that ticket is not related to the "required" setting and still present as of TYPO3 7.6.10.
It might be a Javascript issue:

In file typo3/sysext/backend/Resources/Public/JavaScript/jsfunc.evalfield.js there is line 437:

if (!parseInt(value))    {return '';}

That's why the date 1970-01-01 (with timestamp 0) is erased from the input. Instead it might be enough to check if value is empty?

#12 Updated by Mona Muzaffar over 2 years ago

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

#13 Updated by Riccardo De Contardi about 2 years ago

  • Parent task set to #77562

#14 Updated by Riccardo De Contardi about 2 years ago

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

Also available in: Atom PDF