※2018/8/7 追記
私が検証した環境ではDST時差が「01:00:00」から変更できませんでしたが、「01:00:00」以外に変更可能であることを実機で確認したいただいた方がいます。ブログの最後に関連ツイートを追加しましたのでご確認ください。
※2018/8/7 追記(2)
夏時間規則を登録する際に「別名コピー」で行うとDST時差が変更できず、「新規エントリ」だとDST時差が自由に設定できました。夏時間規則の手順に画面キャプチャを追加しました。
急に出てきたサマータイム案。
導入が決まった場合、システム屋さんで大量のアレがアレすると思います。
SAP ERPに関してはNote摘要等で対応すると思われますが、私自身タイムゾーンの設定を触ったことがないので、実際にどんな仕組みでサマータイムを実現しているか調べてみました。
このへんを参照しながら実機でやってみます
SAP ライブラリ - タイムゾーン (CA-GTF-TIM)
トランザクションコード:SPRO
通常はタイムゾーン「JAPAN」の設定を直接更新すると思いますが、今回はコピーした「XJAPAN」を結成作成。
以下で検証
- DST：+2時間
- 期間は2018年の7月と8月。
※既存のシステムのタイムゾーンは「JAPAN」
まず、「夏時間規則」を登録。
※DST時差が「01:00:00」しか登録できませんでした。ここが「02:00:00」になるはず
※2018/8/7 追記(2)
新規エントリで登録するとDST時差が自由に設定可能
次に「可変夏時間規則」を設定
最後に「タイムゾーン」を設定。
上記で設定した夏時間規則を割当。
作成したタイムゾーンを設定したユーザのローカル時刻を確認。
システム時刻よりもローカル時刻が1時間進んでいることを確認。
こんな感じでした。間違っていたら教えてくださいm(__)m
なんとなく貼っておきます
※2018/8/7追記
SAPのサマータイム対応について調べていたら、こちらのブログがヒットした。で、夏時間規則のDST時差に01:00:00以外設定できないって書いてあったので、実機で試してみた。
— とますさん (@tom_as_san) 2018年8月7日
結論。DST時差は01:00:00以外も設定できます。https://t.co/ZRyt4A1R7c
じゃあ、このブログ主さんが間違っているのか？っていうと然に非ず。
— とますさん (@tom_as_san) 2018年8月7日
SAP長くやってる人には常識だけど、SAP製品はバージョンやらSPレベルやらで結構仕様が変わる。
主さんの環境は1h以外が設定できない仕様だったのかもしれないし、ウチの環境がたまたま1h以外も設定できる仕様だったのかもしれない。
因みに、DST時差のF1ヘルプ出すと「通常は1時間」って書いてあるので、バージョンによっては1h以外は設定できなくてもおかしくないかな。
— とますさん (@tom_as_san) 2018年8月7日
そもそも、DST時差に1h以外を設定するっていうのがイレギュラーなんだろうけど。
いずれにせよ、万が一日本にサマータイムが導入された場合、SAPはLegal changeのNoteでアナウンスをしてくれます。バグ等があれば、修正Noteもリリースしてくれます。
— とますさん (@tom_as_san) 2018年8月7日
ただし、アドオンPGMが動くかは別問題。
タイムゾーンを意識したコーディングをしていないとアウト。
そして、当たり前だけど、SAPがNoteをリリースしてくれても、タイムゾーンのカスタマイズはSAPコンサルマターだし、一通りの動作検証も必要。
— とますさん (@tom_as_san) 2018年8月7日
製品仕様上は問題ないというだけの話で、現場は大変な事になるだろうなぁ…。絶対人手足りなくなるだろうなぁ…。
あ、夏時間規則のDST時差、1h以外も設定できるの確定した。
— とますさん (@tom_as_san) 2018年8月7日
Note：2575107 にオーストラリアのロード・ハウ島のサマータイムの設定値が書いてあるけど、DST時差は30mになってる。
人口350人の小さな島のサマータイムも考慮できるSAP。色々な意味でヤバイな。
タイムゾーンのカスタマイズ等々の詳細情報が必要なSAPコンサルの人は、Note：198411を参考にすると良いですよ。
— とますさん (@tom_as_san) 2018年8月7日
添付のZIPに最新のカスタマイズ情報が網羅されていて、同データは標準ツールでインポートできそうです。
タイムゾーンのメンテナンスは、同Noteのインポートで対応するのが良いかも。
