They are here to support hint(placeholder) and autofocus attribute, if not supported by browser.
In case calendar is having a hint then in non supported browser no placeholder is shown and if field is set to autofocus, it will not get focus onload.

File inclusion is done in the form/field and not in JHtml::Calendar because we are setting both of these attributes in the field.

If this is really used in the HTML of JHtml::calendar, it belongs in JHtml::calendar and not in the field, since otherwise you wouldn't be able to use JHtml::calendar without using JForm. It definitely does not belong in the JForm field.

But it is in the hand of developer, before calling JHtml::calendar, what attributes he is passing and if he passes non supported attributes then he have to take care of the fallback/polyfill. As we are giving a flexibility of adding hint(placeholder) to the calendar form field not to the JHtml::calendar those lines belong there only.

I think JHtml::calendar is used somewhere else also other then calendar form field class. If not, then there is no point of having it in JHtml.

I don't really care if that hands in other attributes or not. Fact is, that you are supposed to be able to swap out stuff like the calendar and that is not really possible if you force some of the output into a different, pretty much unrelated class.

All that said, both the form field class and the JHtml::calendar method are pretty broken and desperately need an overhaul to get all the nasty bugs out. For example it expects the time to always be in UTC, formats it into american format, regardless of what is set and uses $attribs as an array at least 4 times before checking if it is an array.

For example it expects the time to always be in UTC, formats it into american format, regardless of what is set and uses $attribs as an array at least 4 times before checking if it is an array.

Not everything which looks like a bug, is indeed one. The UTC thing for example is a feature. That's because Joomla stores all dates and times as UTC and transforms them back depending on timezone settings. This allows to show the localised date/times depending on user settings (there is a toggle for that).
For the format there is a different PR #2531 (reminds me I should merge that one). However keep in mind that the date is parsed by PHP date functions during save to make it a SQL compatible format. Thus not every format will be detected correctly by PHP. American format is the one which always works.
For the attribs array check: PR welcome. Should be an easy one

Fact is, that you are supposed to be able to swap out stuff like the calendar and that is not really possible if you force some of the output into a different, pretty much unrelated class.

Why is it not possible to swap out the calendar? Or what are you trying to do so we can see the issue?

Looks like it's quite a bit of a standard loading for formfields. It may make sense to load it here especially if the JavaScript is targeted at JForms. Then it would make no sense to load it in JHtml because this one may be loaded in places where the JS doesn't work at all.
Anyway, removing it is not an option at all. One could argue to move it, but removing would break an existing function.

1. The UTC thing is a "bug". It is a change from 2.5 to 3.x. Yes, I know that there is a major revision between those, so a break can occur. The thing is, that I have to add something like 'filter="no_parse"' into my form XML to prevent it to change the timezone. There are legitimate situations, where you want that. Simply putting an empty 'filter=""' in there, wont help here.
2. That part of the code is still a bug, because we allow for the attribute "format" to format our datetimes, but if you don't set the filter or set it to a supported value, it will happily take your formatted value and change the format back to 'Y-m-d H:i:s'. That again then breaks the calendar JS, since that expects the $formated value and instead gets 'Y-m-d H:i:s'.
3. Then there is the question, why we have to do it the special Joomla way in terms of the placeholder attribute. Every developer knows that it is named "placeholder" in HTML, but we have to rename it to "hint", just to rename it back internally.
4. Yes, we have to parse the dates to and back again, but that simply shows one of the biggest issues that I see with JForm. I provide the possibility to format data in a specific way, but that is only for display reasons and will bite us again the moment we save that shit. Instead of JForm being a filer that either generates a form or takes the data from a form and returns the preprocessed data, we only have a little bit of HTML rendering. If this would be done right, there would be no problem to really translate dates into every format out there. Simply read in the format that you output in. Be aware that @infograf768 is working on a change that will translate the date into local formats and it will not format it back for storing that date. (This is from a discussion with a third party) So we will run into this issue very soon.
5. While your PR might be well intended, it will create a lot of grief. As I said, not everybody wants his date/times to be timezone aware.
6. I'm saying that the developers don't have full control over the calendar anymore. Instead of being able to modify the whole calendar by switching out the JHtml::calendar method, they also have to modify the calendar FormField, since that one already forces some output on you. The code in question here, as far as I understand you, is only in there for the placeholder attribute. So why don't we have a check in JHtml::calendar for that attribute and in that case include that stuff, instead of loading it every time, regardless if we need it or not? Why are we forcing people to use this anyway? Maybe I don't give a rats ass what IE8 and below are doing and don't want to load another 80 KB of JQuery and HTML5Fallback?

By now you might have noticed that this agitates me quite a bit. Instead of going the easy way and letting the developer decide which stuff to include and which not, we force a solid 250kb of garbage down everybodys throat. (That is on an empty installation of Joomla 3.1.6, without any sample data, simply loading the empty frontpage. The whole frontpage is 400 kb) We have dozens of options for our fields, but the simple task of having a date from the database and display that in a localized format in an input field, with a placeholder when its empty, and then storing that date back again into the database, requires you to look into the source code of that field to find out that Joomla names the attribute for the placeholder-attribute in its form XML "hint" and it requires quite a lot of messing around with code in your model to get the date formated from one format to the other.

About Calendar formats, IMHO I prefer to store the unix timestamp into database and show the formatted date-time according to specified format which will simplify the code and logic and reduces chances of failure. I know we can't do that right now, but can we consider that for 4.0?

Yes, I agree, loading a comparatively large js file each time is a waste of bandwidth even when it is not required. Even if it is just for providing fallback/polyfill. People who are using old browser should be given an incentive to upgrade their browsers. If we have to provide a polyfill and do things what a browser should do then that browser doesn't deserve to be used for browsing. Like IE x (x belongs to set of Natural numbers) :)

But it is a matter of opinion. Some may feel like this and some other way around. But since we are supporting some of the old browsers in 3.2.x I guess we have to bear this burden for some months.

I see one plus point in using "hint" as replacement of "placeholder" in xml is 7 characters.l know it doesn't worth it but J is special, so it provides hint (a more meaningful literal according to the service it provides). I think w3 should consider changing placeholder to hint.

5.While your PR might be well intended, it will create a lot of grief. As I said, not everybody wants his date/times to be timezone aware.

Actually, my PR doesn't change anything in that regard. It only deals with properly formatting the displayed data according to the format set in the XML. And it fixes an issue with readonly/disabled. Nothing else.

6.I'm saying that the developers don't have full control over the calendar anymore. Instead of being able to modify the whole calendar by switching out the JHtml::calendar method, they also have to modify the calendar FormField, since that one already forces some output on you.

I'm a bit lost here. JHtml::calendar isn't something which is replaced easy. It's way easier to use a custom calendar formfield, loading your own calendar instead (if you're talking from a extension developer view).

So why don't we have a check in JHtml::calendar for that attribute and in that case include that stuff, instead of loading it every time, regardless if we need it or not?

You could have that check in the formfield (not in JHtml where it doesn't belong) I guess. I think it would be a good idea. You just need to know for sure when it really has to be loaded (only for hint and autofocus?). I'd also suggest to do that check then for all formfields where this is used. Because it is used in many of them ;)

Since this PR is rapidly approaching its first anniversary and since this will have to be solved in a different way in the future anyway, I'm closing this one. When the routing is done, I will revisit this and propose a different/better solution.