TL; DR
Никогда не используйте DAYLIGHT SAVING TIME (за исключением очень особых случаев, если вы эксперт)
И хорошо сказано @konstantin:
"Команда CONVERT DATE автоматически позаботится о летнем времени"
Объяснение:
DAYLIGHT SAVING TIME 'X' можно использовать только при местном времени (ДАТА и ВРЕМЯ)соответствует часовому интервалу (редко два часа) для переключения с летнего на зимнее время для данного часового пояса (обратите внимание, что в некоторых часовых поясах нет перехода на летнее время).
Например, в 2003 годуБразилия перешла на зимнее время 9 марта (воскресенье) в 2 часа ночи;в 2 часа ночи пришлось перенести один час назад в 1 час ночи, и, следовательно, 1:30 происходило дважды.
Итак, если ABAP необходимо преобразовать местное время, 2003/03/09 01:30:00 ввремя UTC, оно должно знать, является ли местное время летним временем (зимнее время) или нет (летнее время), что соответственно соответствует времени UTC 2003/03/09 03:30:00 или 2003/03/ 09 04: 30: 00.
Демонстрация:
DATA: time_stamp TYPE timestamp,
dat TYPE d,
tim TYPE t,
tz TYPE ttzz-tzone.
tz = 'BRAZIL'. "UTC-03:00
dat = '20030309'.
tim = '013000'.
CONVERT DATE dat TIME tim DAYLIGHT SAVING TIME 'X' " winter time
INTO TIME STAMP time_stamp TIME ZONE tz.
ASSERT time_stamp = '20030309033000'. " UTC time
CONVERT DATE dat TIME tim DAYLIGHT SAVING TIME ' ' " summer time
INTO TIME STAMP time_stamp TIME ZONE tz.
ASSERT time_stamp = '20030309043000'. " UTC time
Теперь возникает вопрос, как узнать, нужно ли использовать DAYLIGHT SAVING TIME 'X' или нет. Фактически, если таблица базы данных содержит местное время, которое я использовал в приведенном выше примере, никто не может знать , является ли это летним или зимним временем, потому что летнее время никогда не назначается столбцу таблицы вместе сстолбцы даты и времени.
Вот почему SAP представила решение ~ 10 лет назад, которое сделало DAYLIGHT SAVING TIME почти устаревшим. Фактической проблемой было не летнее время, а непостоянное время, которое могло привести к таким проблемам, как хронологическая сортировка. Принцип решения состоит в том, чтобы замедлить время при переходе на летнее время, чтобы одно заданное время никогда не происходило дважды, а время оставалось непрерывным. Технически это влияет на системные переменные SY-DATUM (дата) и SY-UZEIT (время). В этом интервале «двойной час» необходимы две реальные секунды, чтобы сделать одну секунду SAP. Это поведение активируется по умолчанию (значение «включено») через параметр профиля zdate/DSTswitch_contloctime, который вы можете просмотреть через код транзакции RZ11. Ниже приведено время SAP в соответствии со старым («выкл») или новым способом («вкл»), если переключение происходит по местному времени 2 часа ночи (с «вкл» вы не видите переключатель):
off: 1:00, 1:30, 1:00, 1:30, 2:00
on : 1:00, 1:15, 1:30, 1:45, 2:00
Просто чтобы добавить сложности, обратите внимание, что CONVERT все еще имеет разрыв в один час. Например, если для zdate/DSTswitch_contloctime установлено значение «включено» и без DAYLIGHT SAVING TIME, CONVERT даст эти временные метки UTC соответственно, между 03:59:59 и 05: 00: 00: * 1046 будет промежуток в один час. *
3:00, 3:15, 3:30, 3:45, 5:00
Но этот разрыв не является большим недостатком по сравнению с риском возникновения хронологических проблем сортировки.
Дополнительная информация: https://blogs.sap.com/2009/12/09/daylight-saving-time-and-slowing-down-the-time/ и SAP-нота 950114 - Профильпараметр zdate / DSTswitch_contloctime .
Обратите внимание, что SY-DAYST соответствует индикатору DST текущего времени сервера приложений (SY-DATUM, SY-UZEIT и часового пояса, определяемого встол TTZCU). Я не вижу никакого возможного использования этого. Если вы хотите преобразовать время, которое было первоначально получено с помощью SY-DATUM и SY-UZEIT, в метку времени UTC, вы должны использовать метод SYSTEMTSTMP_SYST2UTC класса CL_ABAP_TSTMP. Пример получения текущего времени:
cl_abap_tstmp=>systemtstmp_syst2utc(
EXPORTING
syst_date = sy-datum
syst_time = sy-uzeit
IMPORTING
utc_tstmp = DATA(now_utc) ).
Как продемонстрировал @konstantin (" DATE '20190331' TIME '023000' [...] местное время в Германии не существует" ), CONVERT DATE без DAYLIGHT SAVING TIME может возвращать sy-subrc=12 в редких случаях, если введенные дата и время соответствуют чему-то внутри «исчезающего часа» из-за перехода с зимнего времени на летнее время или если часовой поясимеет летнее времяНапример: «в 2 часа ночи, это 3 часа ночи», местного времени «2:30 утра» вообще не существует.