?
avatar softwareschreiber
softwareschreiber
19 Feb 2016

Steps to reproduce the issue

If I use a form field type 'calendar' the field cannot show dates before 01.01.1970 or after 2038

Expected result

string representation of all dates

Actual result

empty inputvalue

System information (as much as possible)

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));

Additional comments

In source code of Joomla 3.5 this issue exist too.

Best Regards
Hartmut Schreiber

avatar softwareschreiber softwareschreiber - open - 19 Feb 2016
avatar brianteeman brianteeman - change - 20 Feb 2016
Priority Urgent Medium
avatar photodude
photodude - comment - 20 Feb 2016

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.

avatar softwareschreiber
softwareschreiber - comment - 20 Feb 2016

I think too. And it should be no Problem to fix this bug

avatar brianteeman
brianteeman - comment - 20 Feb 2016

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).

avatar GABBAR1947 GABBAR1947 - reference | bf0e41b - 1 Mar 16
avatar GABBAR1947 GABBAR1947 - reference | eb66ea3 - 1 Mar 16
avatar GABBAR1947 GABBAR1947 - reference | 3a5de3d - 1 Mar 16
avatar brianteeman brianteeman - close - 1 Mar 2016
avatar brianteeman
brianteeman - comment - 1 Mar 2016

Closing as we have a PR please test #9271

avatar brianteeman brianteeman - change - 1 Mar 2016
Status New Closed
Closed_Date 0000-00-00 00:00:00 2016-03-01 18:59:52
Closed_By brianteeman
avatar brianteeman brianteeman - close - 1 Mar 2016
avatar photodude
photodude - comment - 3 Mar 2016

@brianteeman Should this be reopened since PR 9271 was rejected as a fix?

avatar brianteeman brianteeman - change - 3 Mar 2016
Status Closed New
Closed_Date 2016-03-01 18:59:50
Closed_By brianteeman
avatar brianteeman brianteeman - reopen - 3 Mar 2016
avatar brianteeman brianteeman - reopen - 3 Mar 2016
avatar flash1452
flash1452 - comment - 5 Mar 2016

@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???

avatar photodude
photodude - comment - 6 Mar 2016

@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)

avatar flash1452
flash1452 - comment - 6 Mar 2016

@photodude Thanks,for your reply.So what other issues are to be handled alongside this one?

avatar brianteeman brianteeman - change - 10 May 2016
Status New Confirmed
avatar brianteeman
brianteeman - comment - 4 Aug 2016

@dgt41 does your new calendar field address this? If so this can be closed

avatar dgt41
dgt41 - comment - 4 Aug 2016

@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

avatar brianteeman
brianteeman - comment - 4 Aug 2016

OK - so I am closing this here as the new (to be merged) calendar will address this as stated above.

avatar brianteeman brianteeman - change - 4 Aug 2016
Status Confirmed Closed
Closed_Date 0000-00-00 00:00:00 2016-08-04 10:15:58
Closed_By brianteeman
avatar brianteeman brianteeman - close - 4 Aug 2016

Add a Comment

Login with GitHub to post a comment