Edit

Page

Page title:

Page body:

[15] 
[[旧Mac]]は[TIME[西暦1904年1月1日0時0分0秒][1904-01-01T00:00:00]]を [N[0]]
とする[[単一数値時刻系]]を使っていました。
現在も[[旧Mac]]に由来する各種システムが採用しています。

[20] 
[[日時]]は[[秒]]を単位とし、
[[日付]]は[[日]]を単位とします。

[21] 
[[時間帯]]は明記した資料があまりありませんが、[[地方時]]と思われます。

[25] [CITE[Approaching the Millennium: The Mac and the Year 2000]], [TIME[2023-11-25T06:39:02.000Z]], [TIME[2014-11-13T17:17:53.003Z]] <https://web.archive.org/web/20141113171013/http://www.fenestrated.net/~macman/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn1049.html>

[FIG(quote)[
[FIGCAPTION[
[1] [CITE@ja-jp[Excel の 1900 年を基準とした日付方式と 1904 年を基準とした日付方式の違いについて]]
([TIME[2017-01-09 17:58:40 +09:00]])
<https://support.microsoft.com/ja-jp/kb/214330>
]FIGCAPTION]

> Microsoft Excel for Macintosh は、デフォルトでは 1904 年を基準とした日付方式を使用しています。初期の Macintosh コンピュータの設計により、1904 年 1 月 1 日より前の日付はサポートされていませんでした。この設計は、1900 年がうるう年ではないことに関連する問題を防止することが目的でした。

]FIG]

[FIG(quote)[
[FIGCAPTION[
[2] [CITE@en[Date - Xojo Documentation]]
( ([TIME[2017-02-11 17:01:19 +09:00]]))
<https://docs.xojo.com/index.php/Date>
]FIGCAPTION]

> A Date object stores the number of seconds since 12:00 AM, January 1, 1904.

]FIG]

[FIG(quote)[
[FIGCAPTION[
[3] [CITE[Unix Time vs. REALBasic time (Real Studio network user group Mailinglist archive)]]
( ([[Christian Schmitz]]著, [TIME[2017-03-04 12:52:02 +09:00]]))
<http://www.monkeybreadsoftware.eu/listarchive-realbasic-nug/2004-04-27-3.shtml>
]FIGCAPTION]

> REAL uses 01/01/1904 as the baseline while Unix uses 01/01/1970 as the 
> baseline

]FIG]

[FIG(quote)[
[FIGCAPTION[
[4] [CITE@ja-jp[Excel の 1900 年を基準とした日付方式と 1904 年を基準とした日付方式の違いについて]]
([TIME[2017-03-10 18:25:56 +09:00]])
<https://support.microsoft.com/ja-jp/help/214330/differences-between-the-1900-and-the-1904-date-system-in-excel>
]FIGCAPTION]

> 2 つの日付方式の日付の差は 1,462 日です。つまり、1900 年を基準とした日付方式の日付のシリアル値は、1904 年を基準とした日付方式の同じ日付のシリアル値よりも常に 1,462 日分大きくなります。

]FIG]

[FIG(quote)[
[FIGCAPTION[
[5] [CITE@ja[Excelだけに存在する日付 | ユニリタブログ]]
([TIME[2017-03-10 18:24:20 +09:00]])
<http://www.unirita.co.jp/blog/data-utilization/data-linkage/20141202.html>
]FIGCAPTION]

> データベースによっては、「特定の日付」より前の日付をマイナス数値で表すものもあるのですが、Excelは
> 「1900年から計算する」設定:「###~###」(扱えない値、の意)
> 「1904年から計算する」設定:絶対値が表す日付に「-」が付く
> (例:1…1904/01/02、-1…-1904/01/02)
> と処理されます。「1904年から計算する」設定ときの動作は、先に記載した日付の計算がマイナスになったときも表示できるようになったことの副作用だと思いますが、マイナスの西暦って何でしょうね?

]FIG]

[FIG(quote)[
[FIGCAPTION[
[6] [CITE@ja[Excelだけに存在する日付 | ユニリタブログ]]
([TIME[2017-03-10 18:24:20 +09:00]])
<http://www.unirita.co.jp/blog/data-utilization/data-linkage/20141202.html>
]FIGCAPTION]

> 「1904年から計算する」設定では、数値「0」を日付に変換すると、上に書いたとおり
>  
> 1904/01/01となります。

]FIG]

[FIG(quote)[
[FIGCAPTION[
[7] [CITE[Standard ECMA-376]] ([TIME[2017-02-28 21:46:40 +09:00]]) <http://www.ecma-international.org/publications/standards/Ecma-376.htm>
[CITE[ECMA-376 1st edition Part 4]]
1919ページ
]FIGCAPTION]

> date1904 (Date 1904)
> Specifies a boolean value that indicates whether the date systems used in the workbook
starts in 1904.
> A value of on, 1, or true indicates the date system starts in 1904.
> A value of off, 0, or false indicates the workbook uses the 1900 date system, where
1/1/1900 is the first day in the system.
> The default value for this attribute is false.
> The possible values for this attribute are defined by the XML Schema boolean datatype.
]FIG]

[FIG(quote)[
[FIGCAPTION[
[8] [CITE@en-gb[time - perldoc.perl.org]]
([TIME[2017-11-06 02:49:29 +09:00]])
<https://perldoc.perl.org/functions/time.html>
]FIGCAPTION]

> On most systems the epoch is 00:00:00 UTC, January 1, 1970; a prominent exception being Mac OS Classic which uses 00:00:00, January 1, 1904 in the current local time zone for its epoch.

]FIG]

[FIG(quote)[
[FIGCAPTION[
[9] [CITE@ja[電子機器の時刻]]
([TIME[2017-01-09 16:20:04 +09:00]])
<http://www.ffortune.net/calen/calen/etime.htm>
]FIGCAPTION]

>  Macintoshのファイル管理システムであるHFS(および後継のHFS+)はファイルの時刻を1904年1月1日起点のLongInt(32bit)の秒数で持っています。1904年1月1日0時0分0秒の2**32=4294967296秒後は2040年2月6日6時28分16秒になるので、それをすぎると問題が生じることになります。

]FIG]

[FIG(quote)[
[FIGCAPTION[
[10] [CITE@ja[Joel On Software私訳]]
([TIME[2020-11-28T06:15:12.000Z]])
<https://anond.hatelabo.jp/20080227113835>
]FIGCAPTION]

> Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。
> Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。
> 1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルがWindowsとMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelはファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。
> 実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙なディティールを発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelのソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙なビットを全て完全に記述することはできない。

]FIG]

[11] 
[[OpenType]]
の
[DFN[[CODE[LONGDATETIME]]]]
は、
[TIME[1904-01-01T00:00]]
からの[[秒数][整数時刻系]]の[[符号付き64ビット整数]]です。

[FIG(quote)[
[FIGCAPTION[
[12] [CITE@ja-jp[年がうるう年かどうかを判断する方法 | Microsoft Docs]]
([[simonxjx]], [TIME[2021-03-01T07:35:38.000Z]])
<https://docs.microsoft.com/ja-jp/office/troubleshoot/excel/determine-a-leap-year>
]FIGCAPTION]

> Excel 97 より前のバージョンの Microsoft Excel では 1900 年から 2078 年までの間にしか処理しないため、1900 年だけが、Microsoft Excel のうるう年の 100/400 除外規則の対象となります。 ただし、他のプログラムとの互換性を保つために、Microsoft Excel では 1900 年をうるう年として扱います。

]FIG]

[FIG(quote)[
[FIGCAPTION[
[13] [CITE[MEW3 PktCDateLib]]
([TIME[2021-05-24T08:12:51.000Z]], [TIME[2000-12-02T20:48:14.917Z]])
<https://web.archive.org/web/20001202204800/http://www3.gamewood.net/mew3/pilot/pocketc/pktcdate/index.html>
]FIGCAPTION]

> This function is limited to the valid dates supported by PalmOS which are 1 January 1904 until 12 December 2031.

]FIG]

[FIG(quote)[
[FIGCAPTION[
[14] [CITE@en[PDB (Palm OS) - Wikipedia]]
([TIME[2021-05-10T08:12:27.000Z]], [TIME[2021-05-24T08:13:56.827Z]])
<https://en.wikipedia.org/wiki/PDB_(Palm_OS)#PDB_Datetimes>
]FIGCAPTION]

> Many PDB format files used times counting in seconds from 1904-01-01T00:00:00. This is the base time used by the original Macintosh (up to Mac OS 9). It may be noted that there were close links between Palm OS and Mac OS during early development. Using an unsigned 32-bit integer and the 1904 epoch, integer overflow will overflow will occur sometime in 2040.
> Others may be observed to be counting from 1970-01-01T00:00:00 (the Unix epoch base time), and uses a signed 32-bit integer which will overflow sometime in 2038.

> If the time has the top bit set, it's an unsigned 32-bit number counting from 1st Jan 1904
> If the time has the top bit clear, it's a signed 32-bit number counting from 1st Jan 1970.
> This is based on the idea that, otherwise the time would be before 1972 or before 1970 (depending on the interpretation) and the PDB format wasn't around then.
> The palmdump utility and other software uses this rule-of-thumb when reading files.

]FIG]

[26] [CITE[Palm OS Protein C/C++ Compiler Language and Library Reference - PalmOS_API_Compiler_Ref.pdf]], [TIME[2017-02-06T20:17:30.000Z]], [TIME[2023-11-25T07:00:55.543Z]] <http://apitechwriter.com/Samples/PalmSource/PalmOS_API_Compiler_Ref.pdf#page=244>

[27] [CITE[subject:"Re\: Date limited to 2031"]], [TIME[2023-11-25T07:01:22.000Z]] <https://www.mail-archive.com/search?l=palm-dev-forum@news.palmos.com&q=subject:%22Re%5C%3A+Date+limited+to+2031%22&o=newest&f=1>

[28] [CITE[Palm, Inc. - Year 2000 Limited Warranty]], [TIME[2023-11-25T07:01:41.000Z]], [TIME[2001-01-19T18:06:08.779Z]] <https://web.archive.org/web/20010119180600/http://www.palm.com/support/helpnotes/palmapps/year2000.html>

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

>[SNIP[]]Palm OS also uses a 7-bit field for storing the year value, with a different epoch counting from 1904, resulting in a maximum year of 2031 (1904+127).

[16] [CITE@ja[アップルと西暦2000年問題 - システムソフトウエア]], [TIME[2020-12-08T04:07:09.000Z]], [TIME[2021-06-08T02:57:40.466Z]] <http://radioc.web.fc2.com/weblib/y2k/apple/os.htm>

[17] [[1900 date system]]

-[18] [CITE@en[Basic Data Types]], [TIME[2022-07-12T17:05:28.000Z]], [TIME[2022-12-31T09:45:47.083Z]] <https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap4/qtff4.html#%2F%2Fapple_ref%2Fdoc%2Fuid%2FTP40000939-CH206-BBCBIICE>
-- [22] 移転確認 [TIME[2023-11-25T05:21:43.000Z]]

>QuickTime movies store date and time information in Macintosh date format: a 32-bit value indicating the number of seconds that have passed since midnight January 1, 1904.
>
This value does not specify a time zone. Common practice is to use local time for the time zone where the value is generated.
>
It is strongly recommended that all calendar date and time values be stored using UTC time, so that all files have a time and date relative to the same time zone.

- [23] [CITE@en-US[Calendar date and time values | Apple Developer Documentation]], [TIME[2023-11-25T05:21:29.000Z]] <https://developer.apple.com/documentation/quicktime-file-format/calendar_date_and_time_values>

[19] [CITE@en[Time formatting and storage bugs - Wikipedia]], [TIME[2023-11-24T03:13:21.000Z]], [TIME[2023-11-25T05:10:33.721Z]] <https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_1993>

>Mac SCI would attempt to use the date to determine how long a delay should last by getting the current time in seconds since 1 January 1904, the Macintosh epoch, and dividing by 12 hours. The division was processed by the Motorola 68000 and would not occur if an overflow was detected because of the division, but the Mac SCI would continue on regardless as if the division had occurred, eventually resulting in a delay of one second being treated as a delay for 18 hours and so on. Sierra released a patch called MCDATE that resolved the problem for almost 14 years.

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

>On 28 May 2007, the Motorola 68000 again does not divide due to overflow protection, which the Mac SCI ignores.

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

>Early Apple Macintosh computers store time in their real-time clocks (RTCs) and HFS filesystems as an unsigned 32-bit number of seconds since 00:00:00 on 1 January 1904. After 06:28:15 on 6 February 2040, (i.e. 232−1 seconds from the epoch), this will wrap around to 1904;[SNIP[]]

[FIG(quote)[
[FIGCAPTION[
[123] [CITE@ja[第66回 モジュールによる時間の多様な取り扱い(1):Perl Hackers Hub|gihyo.jp … 技術評論社]]
([TIME[2021-04-19T00:15:00.000Z]], [TIME[2021-04-19T11:29:21.509Z]])
<https://gihyo.jp/dev/serial/01/perl-hackers-hub/006601>
]FIGCAPTION]

> UNIX時間は,例外的にClassic Mac OSなど一部の古いシステムでは,UTC1904年1月1日00:00:00が紀元になることがあります。

]FIG]

[31] [[1904 time system]] を誤って[[UNIX時間]]と呼んだ事案。

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)