Issue confirmed. Test com_fields in Article.

I am not sure we can set dates older than 1900 in a gregorian calendar (because of UNix limits).

I thought we were limited to 1970 due to unix oimitations. We are validating the dates here so it wouldn't be possible. Alternatively if you needed it in a custom field you could write a custom field to handle it without specific calendar validation. And instead Store as a string.

@tonypartridge no it will go back to 1900 - just take a look ;)

		JoomlaCalLocale.minYear          = JoomlaCalLocale.minYear ? JoomlaCalLocale.minYear : 1900;
		JoomlaCalLocale.maxYear          = JoomlaCalLocale.maxYear ? JoomlaCalLocale.maxYear : 2100;

https://github.com/joomla/joomla-cms/blob/staging/media/system/js/fields/calendar.js#L75

so its expected Behaviour?

It is working as designed BUT that doesn't mean it is correct.

@dgt41 is there a reason for those min and max values?

@brianteeman I thought that we covered that in the layout: https://github.com/joomla/joomla-cms/blob/staging/layouts/joomla/form/field/calendar.php#L128-L129

So with an override you could have user defined values for minimum and maximum year!
PS. If it's multilingual, with mixed calendars (e.g. jalali + gregorian) the override might need to pass the right values depending on the language.

limitation comes from use of strtotime() functions in the calendar.
you can save any date in MySQL but it can be broken by strtotime()
see notes http://php.net/strtotime

php DateTime has no such limits

@Fedik you are right but only for 32bit installations

Quoting

For 64-bit versions of PHP, the valid range of a timestamp is effectively infinite, as 64 bits can represent approximately 293 billion years in either direction.

also true

Not sure if there is a bug here, as we have

• a way to pass custom minimum and maximum year
• there is a known limitation with strtotime() and 32bit versions of PHP

OK to close?

closing - issue can always reopened if needed.