Project

General

Profile

Actions

Bug #37244

closed

Epic #77562: Misbehaviors with datetime values and timezones

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

Added by Tobias Klepp over 12 years ago. Updated over 4 years ago.

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

0%

Estimated time:
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 9 (1 open8 closed)

Related to TYPO3 Core - Bug #21838: Date field on TCA can't accept 1-1-1970 asClosed2009-12-10

Actions
Related to TYPO3 Core - Feature #61110: Support for timezones in all date fields in TYPO3 BENew2014-08-21

Actions
Related to TYPO3 Core - Bug #53640: js validation for datetime + required doesn't work for below 1970ClosedGeorg Ringer2013-11-14

Actions
Related to TYPO3 Core - Bug #61952: bug dbType for date before 01-01-1970Closed2014-09-29

Actions
Related to TYPO3 Core - Bug #69290: Dates get reduced by a day if before 1970Closed2015-08-24

Actions
Related to TYPO3 Core - Bug #69287: Can't enter years before 1902 in date-fieldsClosed2015-08-24

Actions
Related to TYPO3 Core - Bug #73871: Problem with date FieldClosed2016-03-02

Actions
Related to TYPO3 Core - Bug #79448: Handling dates in the very past inside T3-BackendClosed2017-01-24

Actions
Related to TYPO3 Core - Bug #91508: It is not possible to save "negative" dates, e.g. a year before jesus christus with date inputsClosed2020-05-27

Actions
Actions #1

Updated by Steffen Gebert over 12 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.

Actions #2

Updated by Xavier Perseguers over 12 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...)

Actions #3

Updated by Susanne Moog over 12 years ago

  • Status changed from New to Accepted
  • Complexity set to medium
Actions #4

Updated by Jigal van Hemert over 12 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
Actions #5

Updated by Mathias Schreiber almost 10 years ago

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

WIP

Actions #6

Updated by Benni Mack over 9 years ago

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

Updated by Susanne Moog over 9 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #8

Updated by Sebastian Schmal about 9 years ago

the same problem in T3 6.2.15

1902 is the last date that works
1901 jump on 2015

:(

Actions #9

Updated by Benni Mack about 9 years ago

  • Target version changed from 7.5 to 7 LTS
Actions #10

Updated by Mathias Schreiber about 9 years ago

  • Target version deleted (7 LTS)
Actions #11

Updated by Mario Lubenka over 8 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?

Actions #12

Updated by Mona Muzaffar over 7 years ago

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

Updated by Riccardo De Contardi over 7 years ago

  • Parent task set to #77562
Actions #14

Updated by Riccardo De Contardi over 7 years ago

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

Updated by Mathias Schreiber over 4 years ago

  • Status changed from Accepted to Closed
  • Assignee deleted (Mathias Schreiber)

fixed (make sure your integer field is signed

Actions #16

Updated by Daniel Siepmann 10 months ago

  • Related to Bug #91508: It is not possible to save "negative" dates, e.g. a year before jesus christus with date inputs added
Actions

Also available in: Atom PDF