Bug #37244
closedEpic #77562: Misbehaviors with datetime values and timezones
TCA date evaluation for dates lower 01-01-1970 fails
0%
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', ) ),
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.
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...)
Updated by Susanne Moog over 12 years ago
- Status changed from New to Accepted
- Complexity set to medium
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
- 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
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
Updated by Benni Mack over 9 years ago
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
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
:(
Updated by Benni Mack about 9 years ago
- Target version changed from 7.5 to 7 LTS
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?
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 Mathias Schreiber over 4 years ago
- Status changed from Accepted to Closed
- Assignee deleted (
Mathias Schreiber)
fixed (make sure your integer field is signed
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