If I use a form field type 'calendar' the field cannot show dates before 01.01.1970 or after 2038
string representation of all dates
empty inputvalue
The reason is the use of strftime() in html.prg function calendar():
$inputvalue = strftime($format, strtotime($value));
better could be:
$dat = DateTime::createFromFormat("Y-m-d H:i:s", $value);
$inputvalue = $dat->format(str_replace('%','',$format));
In source code of Joomla 3.5 this issue exist too.
Best Regards
Hartmut Schreiber
Priority | Urgent | ⇒ | Medium |
I think too. And it should be no Problem to fix this bug
Pull requests are welcome
On 20 Feb 2016 8:34 pm, "softwareschreiber" notifications@github.com
wrote:
I think too. And it should be no Problem to fix this bug
—
Reply to this email directly or view it on GitHub
#9169 (comment).
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-03-01 18:59:52 |
Closed_By | ⇒ | brianteeman |
@brianteeman Should this be reopened since PR 9271 was rejected as a fix?
Status | Closed | ⇒ | New |
Closed_Date | 2016-03-01 18:59:50 | ⇒ | |
Closed_By | brianteeman | ⇒ |
@brianteeman Sorry,but i am unable to understand what actually this issue is all about.Is it about calendar not showing dates before 01.01.1970 or after 2038 (which is certainly the issue with the operating system one is using) OR is there something else that i am missing???
@flash1452 The code used for the calendar to "Format a local time/date according to locale settings" has system specific limitations. Preventing the calendar from using dates before 01.01.1970 or after 2038 on some systems (limitation is more specifically addressed in my first response).
An alternative to strftime()
should be implemented to allow for correct function on all supported web servers. (unfortunately, there are some BC gotcha issues to deal with too while fixing this issue)
@photodude Thanks,for your reply.So what other issues are to be handled alongside this one?
Status | New | ⇒ | Confirmed |
@brianteeman there are tags in the xml for the field where a dev can set the min and max year that the field should accept. if nothing is provided then 1970 is the minimum and 2030 is the maximum by default (that was a blind copy over the params that existed in the old calendar). So I guess it will be handled better than the current code
OK - so I am closing this here as the new (to be merged) calendar will address this as stated above.
Status | Confirmed | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-04 10:15:58 |
Closed_By | ⇒ | brianteeman |
Looks like there is a Known issue with using PHP's
strftime()
as "Not all conversion specifiers may be supported by the system's C library". More specifically, "dates prior to Jan 1, 1970 - will not work on Windows, some Linux distributions, and a few other operating systems". Additionally, "on some systems the date range may be limited to no earlier than the Unix epoch".Reference on this issue PHP manual for
strftime()
Looks like there are a large number os systems specific caveats for using this function.