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.
Category:
FormEngine aka TCEforms
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',
)
),
- 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.
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...)
- Status changed from New to Accepted
- Complexity set to medium
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
- Assignee set to Mathias Schreiber
- Target version set to 7.1 (Cleanup)
- Is Regression set to No
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
- Target version changed from 7.4 (Backend) to 7.5
the same problem in T3 6.2.15
1902 is the last date that works
1901 jump on 2015
:(
- Target version changed from 7.5 to 7 LTS
- Target version deleted (
7 LTS)
#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?
- Related to Epic #80852: Datetime handling in backend added
- Parent task set to #77562
- Related to deleted (Epic #80852: Datetime handling in backend)
- Status changed from Accepted to Closed
- Assignee deleted (
Mathias Schreiber)
fixed (make sure your integer field is signed
- Related to Bug #91508: It is not possible to save "negative" dates, e.g. a year before jesus christus with date inputs added
Also available in: Atom
PDF