Edit

Page

Page title:

Page body:

*TOD

[6] 
[CITE@en-US[TOD Clock Service - IBM Documentation]], [TIME[2023-01-01T08:29:06.000Z]] <https://www.ibm.com/docs/en/zos/2.4.0?topic=services-tod-clock-service>

>The time-of-day (TOD) clock service provides a caller, including your exit routine, with a TOD clock image. The service supports values from May 11,1971, at 11:56:53.685248 to January 25, 2114, at 11:50:41.055743. In the clock image, bit 0 being off does not mean that the value was within the standard epoch (which began on January 1, 1900, at 12:00 AM). Rather, it means that the value is within the first epoch (which begins on September 17, 2042, at 23:53:47.370496). The system truncates partial microseconds and does no rounding.

[2] 
[CITE@en-us[02.1日付と時刻を得る(TIMEとTOD時計) » 「メインフレーム・コンピューター」で遊ぼう]], [TIME[2023-01-01T08:08:25.000Z]] <http://www.arteceed.net/968.html>

>TOD時計(TOD Clock)はハードウェアのタイマー機構の1つです。実際の時刻を示し、すべてのCPUで共用されます。
>TOD時計は64ビットの2進数カウンターで、ビット51が1マイクロ秒(1/1000000秒)を示します。1マイクロ秒毎にビット51に1が加算されます。1マイクロ秒未満のビット52?63はハードウェア性能によって分解能が変わるため時刻表示には使われません。しかしどのモデルであってもビット51は正しく1マイクロ秒毎に加算されるように設定されます。またビット31は1.048576秒毎に加算されます。ほぼ1秒です。そのためプログラムによってはTOD時計の先頭ワードのみを参照すれば、現在の日付と時刻を得るのに十分な精度が得られます。

>STCKはCPU命令です。現在のTOD時計の値をダブルワードの領域に格納します。STCKEはSTCKの拡張版で、ESA/390アーキテクチャー以降104ビットに拡張されたTOD時計の値を16バイトの領域に格納します。104ビットに拡張されたTOD時計も先頭のビット0?ビット51までは同じです。ビット51は1マイクロ秒を示します。将来の新CPUモデルでは2043年にTOD時計が一周してビット0が繰り上がると、STCKE命令で格納される先頭バイトに格納されるようになっています。プログラムは引き続き1900年を起点にする標準エポックで計時が可能になります。2043年以降も使われるプログラムを作るならSTCKE命令による拡張されたTOD時計のフォーマットと返答領域について知っておく必要があります。現時点で2043年以降のTOD時計について技術情報が公開されているのはIBM社のzアーキテクチャーだけです。

[9] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2023-11-24T03:13:21.000Z]], [TIME[2023-11-25T07:22:52.050Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2042>

*西暦1989年問題

[4] 
[CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2022-12-28T01:04:23.000Z]], [TIME[2023-01-01T08:24:20.807Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_1989>

>Some mainframe programs were written to encode dates as the number of days since a 'zero date' of 1 January 1900, storing them as signed 16-bit binary integers. On 18 September 1989, these programs began to fail, the date being exactly 32,768 (2[SUP[15]]) days since the zero date.[SNIP[]]

*西暦2043年問題

[1] [CITE@en-us[[[2043年問題]] » 「メインフレーム・コンピューター」で遊ぼう]], 
[[神居]],
Posted: 2008/10/09,
Last updated: 2010/06/26,
[TIME[2023-01-01T08:06:20.000Z]] <http://www.arteceed.net/260.html>

>[SNIP[]]S/370アーキテクチャをベースとする汎用機は時刻の制御にTOD時計(Time Of Day clock)と言うものを使っています。TOD時計は64ビットのレジスターで、先頭の52ビット(ビット0?51)が使われます。ビット51は1マイクロ秒(1/1000000)を示し、1マイクロ秒ごとにカウントアップされます。コンピュータが世に登場したのは1950年代以降ですが、この時計の計時基準(スタート時刻)はさらに50年も遡り、1900年1月1日午前0時0分0秒ジャストです。ちなみにこの日は日曜日で週初めでもあります。TOD時計の最初の状態は、x00000000-00000です。-の位置が1.048576秒(約1秒)を示します。やがてマイクロ秒ごとのカウントアップが限界に来るとTOD時計はxFFFFFFFFFFFFFとなります。そしてもう1マイクロ秒で繰り上がってx0000000000000に戻ってしまいます。99年から00年になるのと似た状況が起きるわけです。TOD時計の周期は約143年なので、2043年にこの問題が発生します。すでにIBM社はアーキテクチャでこの問題に対応した新たな仕様を決めていて、z/OS自身の日付計算モジュールや関連するAPIなどもすでに対応されているようです。COBOLやPL/Iで書かれたプログラムでは直接TOD時計を使うことはありませんのでY2Kの時ほど騒がれることはないでしょうが、アセンブラー・プログラムではTOD時計の値を直接使って日付や時刻を計算するプログラムは結構あると思います。[SNIP[]]

[3] [CITE@ja[こだわりの連載技術エッセイ第2部 第5回]], 
[[光]],
2004年8月24日,
[TIME[2010-06-14T12:54:02.000Z]], [TIME[2023-01-01T08:11:11.731Z]] <http://www.asianetwork.co.jp/contents/products/lubricon/column/column/026.html>

>今までの時刻問題がオペレーティング・システムやアプリケーション・プログラムの中に定義された時刻情報の問題であったのに対して「2042年問題」はハードウェアの時刻機能の問題であるのが大きな違いである.
>IBM系のメインフレーム・アーキテクチャではハードウェアがTOD(Time of Day)として64ビットのカウンタを持っている.そのカウンタの値がオールゼロの時はグリニチ標準時で1900年1月1日午前0時と決められており,そのカウンタは1マイクロ秒毎に更新される.
>1960年代から70年代に開発されていたアーキテクチャの時刻の原点を1900年に設定するのはアーキテクチャに美しさを持たせようとしたIBMらしいと筆者は感じる.
>この64ビットのカウンタが2042年9月17日午後11時53分46秒頃に一杯になりオール1になる.(日本時間 18日午前8時53分46秒頃) ソフトウェアのインターフェース上では無くハードウェアの基本のタイマーであるので事態はより深刻かも知れないが,今から拙速に対応するのでは無くあと38年もあるので良く考えるときっと良い解決方法が出てくるものと筆者は信じている.

[5] [CITE@ja-JP[時刻および日付の時刻機構 (TOD) 形式への変換 - IBM Documentation]], [TIME[2023-01-01T08:27:03.000Z]] <https://www.ibm.com/docs/ja/zos/2.2.0?topic=tc-converting-between-time-day-date-tod-clock-formats>

>アプリケーションを ETOD 形式を使用するものに変換することをお勧めします。 拡張時刻形式は 2042 年に発生する時刻ラッピング問題へ対処するため、 および、高速プロセッサーが使用可能になったときに必要となる、改善された精度を 提供するためにも必要です。

* 西暦2079年問題

[11] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2023-11-24T03:13:21.000Z]], [TIME[2023-11-25T07:51:01.052Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2079>

>[SNIP[]]Some mainframe systems experienced software failures because they had encoded dates as the number of days since 1 January 1900, which produced unexpected negative day numbers on the roll-over date of 18 September 1989. Similarly, unsigned 16-bit binary days counts overflow after 65,536 (2[SUP[16]]) days, which are truncated to zero values. For software using an epoch of 1 January 1900, this will occur on 6 June 2079.[SNIP[]]

* メモ

[7] [CITE@ja[Modelerデータ加工Tips#08-7日後と6ヵ月後の日付データを作成する | IBM ソリューション ブログ]], [TIME[2023-01-01T08:34:49.000Z]] <https://www.ibm.com/blogs/solutions/jp-ja/modeler-tips-08/>

>ちなみに、基準日の初期設定はストリームのプロパティで変更することができます。

[8] [CITE@ja[SPSS ModelerのCLEM式でよく使う「日付と時刻」関数 - Qiita]], [TIME[2023-01-01T08:35:08.000Z]] <https://qiita.com/Makimaki2020/items/72e3b774039327fa4ac4>

>①誕生日のストリーム基準日(デフォルト1900年1月1日)からの経過日数を求めます。

[10] [CITE[Server Time Protocol Planning Guide]], [TIME[2023-11-25T07:23:17.000Z]] <https://www.redbooks.ibm.com/abstracts/sg247280.html>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)