Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in libraries\cms\html\html.php #9169

Closed
softwareschreiber opened this issue Feb 19, 2016 · 11 comments
Closed

Bug in libraries\cms\html\html.php #9169

softwareschreiber opened this issue Feb 19, 2016 · 11 comments

Comments

@softwareschreiber
Copy link

softwareschreiber commented Feb 19, 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

@photodude
Copy link
Contributor

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.

@softwareschreiber
Copy link
Author

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

@brianteeman
Copy link
Contributor

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

@brianteeman
Copy link
Contributor

Closing as we have a PR please test #9271

@photodude
Copy link
Contributor

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

@brianteeman brianteeman reopened this Mar 3, 2016
@flash1452
Copy link
Contributor

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

@photodude
Copy link
Contributor

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

@flash1452
Copy link
Contributor

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

@brianteeman
Copy link
Contributor

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

@dgrammatiko
Copy link
Contributor

@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

@brianteeman
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants