Edit

Page

Page title:

Page body:

[1] [DFN[[[日時]]の処理]]は、簡単に見えて難しいものです。

* 表現

[SEE[ データモデルは[[日時データモデル]] ]]

[SEE[ 構文やデータ型は[[日時形式]] ]]

* 演算

[FIG(short list)[ [8] [DFN[[[日時]]の[[演算]]]]
- [[期間計算]]
- [[日暦算]]
- 所属と前後日時の取得
-- [[前日]]、[[今日]]、[[翌日]]
-- [[前週]]、[[今週]]、[[来週]]
-- 直近7日
-- [[前月]]、[[今月]]、[[翌月]]
-- 直近30日
-- [[四半期]]
-- [[半期]]
-- [[昨年]]、[[今年]]、[[来年]]
-- [[月初]]、[[月末]]
-- [[月度]]
-- [[年度]]
- [[日時の比較]]
- [[日時の整列]]
- [[暦の換算]]
-- [[曜日]]
- 一覧の取得
-- [[年]]の一覧
-- [[年]]内の[[月]]の一覧
-- [[月]]内の[[日]]の一覧
- [[月]]の[[カレンダー]]の構成
- [[日時入力]]
- 機械的入力の[[構文解析]]
-- [[日時形式]]
- 文字列化
-- [[日時形式]]
-- [[日時表示]]
]FIG]

[35] [CITE@en-us[Common options | Elasticsearch Guide '''['''8.11''']''' | Elastic]], [TIME[2023-11-24T15:20:54.000Z]], [TIME[2023-11-25T08:53:57.488Z]] <https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#date-math>

* 問題

[6] [[日時]]を[[計算機システム]]等で処理する際には、
様々な問題に注意する必要があります。

[FIG(short list)[ [7] [[日時処理]]の問題
- [[日時のセキュリティー]]
- [[日時のプライバシー]]
- [[日時桁溢れ問題]]
-- [[2000年問題]]
-- [[2038年問題]]
- [[閏年]]
- [[閏秒]]
- [[時刻同期]]
- [[夏時刻]]
-- [[夏時刻システム障害]]
- [[改暦]]
-- [[過去の日時]]
-- [[将来の日時]]
-- [[改元]]
-- [[標準時改正]]
- [[暦の換算]]
- [[西暦和暦誤認バグ]]
- [[暦年週年バグ]]
- [[日時計算ソフトウェアのパフォーマンス問題]]
- [[日時特殊値]]

]FIG]

[25] 
[[日時]]という[[系]]の複雑性に起因する問題もあれば、
[[日時]]を実装するためのモデル化の失敗による問題もあります。
[[日時制度]]の改正の実施・適用という社会システム運用の問題もあります。
[[日時]]とは無関係の[[プログラミング]]やシステム開発的な問題がたまたま[[日時処理]]に害を及ぼした場合もあります。

[26] 
社会の[[情報化]]の進展に伴って、[[日時処理]]の失敗の影響範囲はますます拡大し、
それ自体が社会問題化するようになりました。

[27] 
[[西暦2000年問題]]はその端緒であり、代表例といえます。
その後も[[日時処理]]の問題が起こるたびに、
[[西暦2000年問題]]の再来のような言われ方をしています。
[SEE[ [[西暦2020年問題]], [[西暦2021年問題]], [[西暦2038年問題]], [[令和改元]], [[暦年週年バグ]] ]]

-*-*-

- [18] [CITE@en-us[Apple says Do Not Disturb scheduling is broken until January 8 | Ars Technica]], [TIME[2022-07-10T08:37:17.000Z]] <https://arstechnica.com/gadgets/2013/01/apple-says-do-not-disturb-scheduling-is-broken-until-january-7/?comments=1&start=40#comment-23649245>
(コメント欄2ページ目)
-- [19] [[Korpo]], Jan 3, 2013 8:42 AM

>December was missing in the People app, not "completely nuked" or "lost in Android". It was the People app included with a specific version of Android, and only certain localizations (including English).
>
-If you didn't bother upgrading your phone before December, the date/time on your phone would have gone to December just fine.
-If you tried to set an appointment or schedule something to happen in December, it would work just fine.
-If you set someone's birthday or anniversary or something via the web interface (google.com/contacts) It would sync and show them properly.
-If you tried to set/change someone's birthday or anniversary via the People app on a 4.2.0 Android phone for the three weeks it was broken, and you were using an affected language, you'd have issues. The humanity.

;; [20] 
「Android で12月がなくなる不具合があった」
のようなキャッチーだけど雑な情報を流している人に苦言を呈している。
そういうのが広がりがちで真相が見えづらくなるので、詳しい情報[[たすかる]]。

[24] [CITE@en[December month missing in calendar '''['''36958380''']''' - Visible to Public - Issue Tracker]], [TIME[2022-07-10T10:06:42.000Z]] <https://issuetracker.google.com/issues/36958380#c46>

[21] [CITE@en-US[Android 4.2 bug omits December from the People app, makes end-of-year birthdays even less bearable | Engadget]]
([TIME[2022-07-10T09:11:55.000Z]])
<https://www.engadget.com/2012-11-18-android-4-2-bug-omits-december-from-the-people-app.html>

[23] [CITE@en[Google cancels Christmas? Why Android can't remember December | Android | The Guardian]], [TIME[2022-07-10T10:05:30.000Z]] <https://www.theguardian.com/technology/blog/2012/nov/18/android-december-lost-birthday>

[22] 
[[クリスマス中止のお知らせ]]は[[草]]

[36] 
[CITE@ja[年金問題、生年月日の日付を丸めて記録?? | スラド]], [TIME[2024-01-22T12:31:27.000Z]] <https://srad.jp/story/07/10/26/0226214/>

* 実装

[FIG(short list)[ [2] [[日時処理]]の実装
- [CODE[[[Date]]]]
- [CODE[[[DateTime.pm]]]]
- [CODE[[[Time::Piece]]]]
- [[Noda Time]]
- [[XFDLの日時処理]]
- [[XDMの日時処理]]
]FIG]

* 関連

[4] [[日次処理]]はまた違います。

* メモ

[3] [CITE[The Best Of Dates, The Worst Of Dates]], [[Gilbert Healton]], [TIME[2016-02-13 05:20:01 +09:00]] <http://x109.healton.net/y2k/yrexamples.html>

[5] [CITE['''['''tz''']''' Temporal - ECMAScript built-in JS Library for dates/times/timezones/calendars in progress]]
([TIME[2021-03-04T21:11:34.000Z]], [TIME[2021-03-05T01:51:17.570Z]])
<https://mm.icann.org/pipermail/tz/2021-March/029899.html>

[9] [CITE@ja[タイムゾーン呪いの書 (知識編)]], [TIME[2021-07-07T00:54:22.000Z]] <https://zenn.dev/dmikurube/articles/curse-of-timezones-common-ja>

[10] [CITE@en[COCOA v1.4.0 が起動しない · Issue #517 · cocoa-mhlw/cocoa · GitHub]], [TIME[2021-11-30T09:48:11.000Z]] <https://github.com/cocoa-mhlw/cocoa/issues/517#issuecomment-978988403>

> [CODE[DateTime()]]は[CODE[0001/01/01 0:00:00]]で、そこからさらに9時間を引こうとしているので怒られている。
> DateTime.MinValueと同値であれば引かないようにとか考えたけど、DateTime.MinValueと同値ではない[CODE[0001/01/01 0:08:00]]から9時間引こうとするとやっぱり落ちるよねと。

[FIG(quote)[
[FIGCAPTION[
[11] [CITE@ja[DateTime.MinValue や new DateTime() は危険 - Cube Lilac]]
([[clown]], [TIME[2021-11-30T09:53:39.000Z]])
<https://clown.cube-soft.jp/entry/2021/11/26/datetime-trap>
]FIGCAPTION]

> 例えば、DateTime.MinValue.ToUniversalTime() は、予想に反して、例外を発生させずに正常終了します(日時の値は変更されずにタイムゾーンの値のみ UTC になる)。ただ、DataContractJsonSerializer の事例のようにライブラリ側で変換処理が実行されて例外が発生する事も多いため、万全を期すのであればライブラリに指定する全ての DateTime オブジェクトに対して ToUniversalTime 等を実施しなければならず、結構な負担となります。

]FIG]

[12] [CITE@ja[606さんはTwitterを使っています 「Dropboxがおかしくて、毎回、関ヶ原終わりたてホヤホヤの頃のExcelファイルが出土されます 巻物でやれ https://t.co/hCLpKXDfde」 / Twitter]]
([TIME[2022-01-20T08:18:34.000Z]], [TIME[2022-01-21T01:39:14.102Z]])
<https://twitter.com/bumWings/status/1483989654378405888>

[13] [CITE@ja-jp[日付と時刻のデータ型および関数 - SQL Server (Transact-SQL) | Microsoft Docs]], [[markingmyname]], [TIME[2022-04-22T09:07:51.000Z]] <https://docs.microsoft.com/ja-jp/sql/t-sql/functions/date-and-time-data-types-and-functions-transact-sql?view=sql-server-ver15>

-
[14] 
[CITE[時間情報を取り扱うための課題の整理を試みる―日本史資料を題材に―]],
[[後藤真]]
-- [15] 
[CITE[第25回「東洋学へのコンピュータ利用」研究セミナー]], [TIME[2014-03-15T00:43:49.000Z]], [TIME[2022-04-28T08:52:42.771Z]] <http://kanji.zinbun.kyoto-u.ac.jp/seminars/oricom/2014.html>
-- [16] 
[CITE@ja[第25回「東洋学へのコンピュータ利用」研究セミナー(#zinbun #jinbun) (2ページ目) - Togetter]], [TIME[2022-04-28T08:52:51.000Z]] <https://togetter.com/li/642076?page=2>

[17] 
[TIME[2022-06-04T13:26:14.200Z]]
<http://www.libraryjournal.com.cn/EN/article/downloadArticleFile.do?attachType=PDF&id=2289>

[28] [CITE@ja[programming and calendar]], [TIME[2022-07-13T08:22:44.000Z]], [TIME[2004-02-03T18:31:26.408Z]] <https://web.archive.org/web/20040203182933/http://www.funaba.org/en/programming-and-calendar.html>

[29] [CITE@ja-JP[Supported Presto and TD Functions - Product Documentation - Treasure Data Product Documentation]], [TIME[2022-08-25T00:18:23.000Z]] <https://docs.treasuredata.com/display/public/PD/Supported+Presto+and+TD+Functions>

[30] [CITE@ja-jp[datetimeV2 作成済みエンティティ - LUIS - Azure Cognitive Services | Microsoft Learn]], [[aahill]], [TIME[2023-01-01T08:22:55.000Z]] <https://learn.microsoft.com/ja-jp/azure/cognitive-services/luis/luis-reference-prebuilt-datetimev2?tabs=1-1%2C2-1%2C3-1%2C4-1%2C5-1%2C6-1>

[32] [CITE[How to save datetimes for future events - (when UTC is not the right answer)]], [TIME[2021-03-03T04:39:21.000Z]], [TIME[2023-06-06T14:30:41.050Z]] <http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html>

[31] [CITE@en[Storing UTC is not a silver bullet | Jon Skeet's coding blog]], [TIME[2023-06-06T14:18:20.000Z]], [TIME[2023-06-06T14:30:17.380Z]] <https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/>

[33] [CITE@en[JRS - Critical and Significant Dates - J R Stockton]], [TIME[2023-06-06T14:35:19.000Z]], [TIME[2015-09-08T00:59:13.478Z]] <https://web.archive.org/web/20150908004245/http://www.merlyn.demon.co.uk/critdate.htm>

[34] [CITE@en[ruby/lib/time.rb at master · ruby/ruby · GitHub]], [TIME[2023-09-11T03:54:55.000Z]] <https://github.com/ruby/ruby/blob/master/lib/time.rb>

- [38] 
[CITE@en[Apple confirms New Year's alarm bug, says to wait until Jan 3 | AppleInsider]], [TIME[2024-01-27T05:25:22.000Z]] <https://appleinsider.com/articles/11/01/01/apple_admits_new_years_alarm_bug.html>
- [37] 
[CITE@ja[アップルのiOS、元旦に目覚ましがならないバグ | スラド アップル]], [TIME[2024-01-27T05:25:13.000Z]] <https://apple.srad.jp/story/11/01/02/084250/>

- [41] 
[CITE@ja[XユーザーのMakoto Kamadaさん: 「X68000 LIBRARYにLHA.x 2.62を収録しました。 https://t.co/JyyCjlQSAw LHA.x 2.60→2.62で以下の不具合を修正していただきました。 (1)圧縮時、-lh0-の後に-lh5-があると展開できないアーカイブファイルが作られる (2)圧縮時、ファイルのタイムスタンプが閏年の2月のとき翌日の日付が書き込まれる」 / X]], [TIME[午後8:28 · 2024年7月21日][2024-07-21T11:28:11.000Z]], [TIME[2024-07-22T02:30:46.000Z]] <https://x.com/kamadox/status/1814985722568618412>
-- [39] [CITE@ja[XユーザーのMakoto Kamadaさん: 「LHA.x 2.60で日付がずれたのはlibcの_getydayのバグが原因。_getydayは年と月から1日(ついたち)の年通日を求める関数で、閏年の3月以降のとき年通日に2月29日の分の1を加える処理が、誤って2月以降になっている。mktimeに2024年2月1日を与えて繰り返し呼び出すと日付が増えてゆくことで確認できる。 https://t.co/REyIvxNSLk」 / X]], [TIME[午前1:09 · 2024年7月22日][2024-07-21T16:09:19.000Z]], [TIME[2024-07-22T02:30:46.000Z]] <https://x.com/kamadox/status/1815056470737871210>
-- [40] [CITE@ja[XユーザーのMakoto Kamadaさん: 「libcの_getydayのバグは過去にも指摘されていて修正パッチがある。ライブラリを更新するときはmakeが通らなくなったり同じバージョン表記なのに内容が異なるものが混在して混乱を招くことがあるので注意する。」 / X]], [TIME[午前11:19 · 2024年7月22日][2024-07-22T02:19:11.000Z]], [TIME[2024-07-22T02:30:46.000Z]] <https://x.com/kamadox/status/1815209949624246282>

[42] 
[CITE@ja[XユーザーのSTB a.k.a. さとまるさん: 「俺としては、「1.1秒」と書かれたら、それは1秒100,000,000ナノ秒と解釈して欲しいんだけど、DateTimeFormattetはどうやら1秒1ナノ秒と解釈するみたいなんよ。 おかしくない?ねえ、おかしくない?」 / X]], [TIME[午前9:54 · 2025年1月23日][2025-01-23T00:54:09.000Z]], [TIME[2025-01-23T01:21:04.000Z]] <https://x.com/stb_nissie/status/1882230303349260451>

- [43] [CITE@ja[XユーザーのBird 😷さん: 「首都高の渋滞予想カレンダーが表示されない件 NaN月って… https://t.co/L7RX4rv2Gk https://t.co/yiGKbIPcb3」 / X]], [TIME[午前9:31 · 2025年1月4日][2025-01-04T00:31:39.000Z]], [TIME[2025-09-01T03:57:23.000Z]] <https://x.com/bird_ys/status/1875339272565436733>
-- [44] 
[CITE@ja[XユーザーのBird 😷さん: 「正月明けの6日にやっと復旧してた」 / X]], [TIME[午前9:31 · 2025年1月9日][2025-01-09T00:31:36.000Z]], [TIME[2025-09-01T03:57:23.000Z]] <https://x.com/bird_ys/status/1877151199582949829>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)