(jp) =
簡単な質問は次のとおりです。
日付範囲 「2019-01-01 – 2019-01-31」 日付を含む “2019-01-31”?
答えはイエスですよね？
… 右？
範囲が 10 時に終了し、テスト日が 11 時に開始する場合はどうなるでしょうか? 今は重なっていません。
知らないかもしれないより小さな時間単位が常にある場合、どうすれば日付を確実に比較できるでしょうか? 2つの解決策があります。
# 境界を除く
ここで少し数学を復習すると、範囲は次のように記述できます。
[start, end]明らかに、この表記法は日付期間に適用できます。
[2019-01-01, 2019-01-31]角括弧は境界が範囲に含まれることを示し、丸括弧は境界が除外されることを意味します。
(0, 3)この表記法は、この範囲が 0 から 3 までのすべての数値を含むことを示しています。 1 と 2.
排他的境界を使用すると、100% の正確さで日付を比較できます。
かどうかをテストする代わりに [2019-01-01, 2019-01-31] 日付を含む 2019-01-31、どうかテストしてみませんか [2019-01-01, 2019-02-01) contains it?
An excluded end boundary allows us to say that “all dates before 2019-02-01” are contained within this range.
The times of our date and period don’t matter anymore,
we’re always sure that a date before 2019-02-01 will fall within our range.
# Ensuring the same precision
While the above solution mathematically works, it gets awkward in a real world context.
Say we want to note “the whole month of January, 2019” as a range.
It looks like this:
[2019-01-01, 2019-02-01)This is a little counter intuitive, at least it’s not the way we humans think about “January”.
We’d never say “from January 1, until February 1, with February 1 excluded”.
As it goes in programming, we often sacrifice the “common way of human thinking”
to ensure correctness.
But there is a way to ensure program correctness, with the notation that makes sense to humans:
[2019-01-01, 2019-01-31]私たちの問題は、作業している日付の時間がわからなかったため発生しました。 私の提案は、境界を除外して問題を回避するのではなく、完全に排除することです。
問題を回避するのではなく、問題の根本を修正しましょう。 それは常にすべてのプログラマーの考え方であるべきではありませんか?
大事なことなのでもう一度言わせてください。
問題を回避するのではなく、問題の根本を修正しましょう。
ソリューション？ 日を比較するときは、日だけを比較していることを確認してください。 時間、分、秒ではありません。
プログラミングするとき、これは、日付範囲の精度をその範囲内に格納する必要があることを意味します。 また、精度が異なる日付の比較を禁止する必要があることも意味します。
あなたの意見は何ですか？ 経由でお知らせください ツイッター または電子メール。