Restrict the downtime endtime to prevent unremoveable downtimes

[Svido]

Describe the bug

Downtimes with a scheduled endtime after 2038-01-19 will result in an unremoveable downtime. This is probably caused 2038-01-19 is the maximum value in the database (MySQL). mysql > select FROM_UNIXTIME(2147483648); +---------------------------+ | FROM_UNIXTIME(2147483648) | +---------------------------+ | NULL | +---------------------------+ mysql > select FROM_UNIXTIME(2147483647); +---------------------------+ | FROM_UNIXTIME(2147483647) | +---------------------------+ | 2038-01-19 04:14:07 | +---------------------------+

To Reproduce

Provide a link to a live example, or an unambiguous set of steps to reproduce this issue. Include configuration, logs, etc. to reproduce, if relevant.

1. Create a downtime with a scheduled endtime after 2038-01-19 04:14:07.
2. Try to delete the downtime

Expected behavior

Limit the datetimepicker to a date that the database can handle.

Screenshots

If applicable, add screenshots to help explain your problem.

Your Environment

Include as many relevant details about the environment you experienced the problem in

• Icinga Web 2 version and modules (System - About): 2.9.5
• Web browser used: any
• Icinga 2 version used (icinga2 --version): 2.13.2-1
• PHP version used (php --version): 7.3.29
• Server operating system and version: Centos 7

Possible solution

Add 2038-01-19 04:14:07 as the max value for the downtime end datetime-picker. application/views/helpers/FormDateTime.php as described here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local#max

[tectumopticum]

It would be helpful to plan this maximum value as a configuration parameter instead of a hard-coded value in the code: sometimes users set a downtime to a max-value over several years. It should be possible to restrict this by configuration.