Я согласен с Hogstrom в том, что летние / зимние (дневной / стандартный) сдвиги времени изменились и могут измениться в будущем, поэтому, по сути, это проблема, которую необходимо решать и решать заново. Если вы заботитесь о високосных секундах, это аналогичная проблема. Если вам небезразлично недавнее историческое время, в Нидерландах были такие интересные смещения часовых поясов (стандартное время здесь):
с 1 мая 1909 года по 1 июля 1937 года: UTC + 0h19m32.13s (да, серьезно)
с 1 июля 1937 года по 16 мая 1940 года: UTC + 0h20m
Нидерланды наблюдали летнее время с 1916 по 1945 год, прекратили его наблюдать с 1946 по 1976 год, а затем начали снова наблюдать его с 1977 года. И возможно, что Нидерланды не запускали / не заканчивали летнее время последовательно в соответствии с одними и теми же правилами дат в те годы, когда применялся DST. (Я не уверен насчет этой части.) В настоящее время в Европейском Союзе ведутся активные дебаты о гармонизации часовых поясов и, возможно, избавлении от летних / зимних сдвигов, поэтому разумно планировать заранее, чтобы попытаться избежать внедрения Y2K-подобного проблемы в это решение. Что бы вы ни делали, вы хотите попытаться сделать свой код разумно ориентированным на будущее.
ОК, с учетом этого фона, и если поставщик этих связанных со временем данных настаивает на предоставлении местного времени Амстердама, а не помогает вам с UT C, я думаю, у вас должен быть какой-то входной файл, список параметров или таблица, определяющая, как преобразовать местное время из Амстердама в UT C. Вы можете sh выдать ошибку, если / когда представлены даты / время ранее 1 января 1977 года. Если ваше приложение поддерживает какую-либо трассировку или ведение журнала, я бы выписал информацию о том, когда локально для UT C набор правил преобразования времени последний раз обновлялся. Я также добавил бы некоторую информацию о комментариях к коду даты / версии в файл / таблицу / набор правил. Программно примените правила, определенные в этом входном файле, а затем передайте UT C в код, который вы указали выше. Если вы хотите немного поумнеть (в хорошем смысле), вы можете определить правила часового пояса / DST в BRMS, например, в IBM Operational Decision Manager (ODM) для z / OS, если у вас есть это (которое может уже иметь такие правила). ), затем вызовите BRMS из COBOL.
Другая возможность - выполнить преобразование из местного часового пояса / летнего времени в UT C, используя java .time. В этой статье объясняется, как это делается:
https://www.baeldung.com/java-daylight-savings
Естественно, вы можете запускать Java программ в CICS (очень хорошо) и Java Standard Edition является частью базовой операционной системы z / OS, включена и поддерживается без дополнительной оплаты. (Профиль Liberty также является частью CICS Transaction Server, хотя это так просто, что вам не нужна Liberty.)
Здесь опасность состоит в том, что если дистрибьютор Java (в данном случае IBM) или, более Скорее всего, системный оператор не поддерживает текущее время выполнения Java, и тогда ваша программа может применить устаревшее правило преобразования из локального в UT C всякий раз, когда кто-то решит изменить правила в будущем. Поэтому я неохотно предпочитаю какой-то подход на основе файла правил ввода / таблицы / списка параметров.
ОК, а какой входной файл / таблица / список параметров? Ну, база данных о часовых поясах IANA была бы действительно хорошим выбором:
https://data.iana.org/time-zones/tz-link.html
Ваш код, скорее всего, должен обрабатывать только небольшое подмножество этой базы данных, но как «Истина истины» довольно неплохая.