エンジニアリングの理由はありますか？RDBMSの場合、「YEAR」は「MONTH」よりも具体的であるため、パフォーマンスと関係があるのではないかと思っていました。たとえば、2000年は1年しかありませんが、毎年「1月」これにより、年ごとに何かを簡単にフィルタリング/ソートできるようになります。そのため、年が最初になります。

しかし、それが本当に意味をなすかどうかはわかりません...何か理由はありますか？

これにより、デフォルトのソート規則（辞書式ソートなど）を使用して、日付を文字列として簡単にソートできます。

これは、2桁を使用して月と日が指定される理由でもあります（必要に応じて先行ゼロを追加します）。

実際、ISO 8601で定義されている日付形式の1つです。この標準では、日付と時刻の形式も定義して2015-03-27T15:26:40Zいます。これは、文字列としてもソートできます。

ただし、YYYYMMDDには、文字列を整数として簡単に解析でき（部分文字列や文字の置換は不要）、整数のデフォルトの順序を使用できるという利点があります。

まだ言及していませんが、YYYY 内の注文をすぐに確認できます。それはすでに数千年、数世紀、数十年、数年です。つまり、YYYYはすでに最長期間から最短期間に並べられています。同じことがMMとDDにも当てはまります。それがまさにナンバーシステムの仕組みです。

したがって、フィールド間の順序をフィールド内の順序と一致させるために、唯一のオプションはYYYYMMDDです。

zahbazとArseni Mourzenkoが指摘したように、YYYYMMDD形式は簡単に並べ替えられます。それは幸運な偶然ではありません、それはフィールドを最も長い期間最初に置くことの直接的な結果です（そして長さを固定したままにします;ここでY10K問題を導入しています）。

何か理由はありますか？

はい。これらのソフトウェアはISO 8601を使用します。

ISO 8601には、他の日付形式よりも多くの利点があります。

• それは仕様書のある標準です:)
• それは明白です。mm / dd / yyyyとdd / mm / yyyyは、13日目を過ぎないと混乱する可能性があります。
• 昇順の時間順に辞書式にソートされるため、特別な日付ソートロジックは必要ありません。これは、ファイル名で特に役立ちます。ファイル名では、辞書式番号のソートがしばしば混乱します（例：）1_file, 10_file, 2_file。
• 4桁の年とゼロでパディングされた月と年を義務付けています。これにより、2000年問題やその他のあいまいさが回避されます。

なぜ人々があいまいな日付フォーマットを見つけ、混乱国/システム間でデータを交換するとき、彼らは明確な何かが必要だったので、ISO 8601が最初の場所に存在し、それはです。

根拠については、仕様の概要を参照してください。

このフィールドのISO勧告と規格は1971年以来利用可能ですが、日付と時刻の数値表現のさまざまな形式がさまざまな国で一般的に使用されています。そのような表現が国境を越えて交換される場合、数字の重要性の誤解が発生する可能性があり、その結果、混乱およびその他の結果的なエラーまたは損失が生じます。この国際規格の目的は、誤解のリスクを排除し、混乱とその結果を回避することです。

...

この国際標準は、日付と時刻の最も一般的に使用される表現と、以前の国際標準からのそれらの表現を保持し、実際に使用されるいくつかの新しい表現の一意の表現を提供します。特にデータ処理システムと関連機器との間の情報交換におけるそのアプリケーションは、誤解から生じるエラーとそれらが生成するコストを排除します。この国際標準の推進は、国際的な境界を越えた交換を促進するだけでなく、ソフトウェアの移植性を改善し、組織内および組織間のコミュニケーションの問題を緩和します。

標準では、区切り文字の使用を最小限に抑えると「基本的な」バリエーションが定義されています。だから、YYYYMMDDある基本的な拡張フォーマットへの代替YYYY-MM-DD。

それは、他のすべての方法があいまいだからです。

2003年1月2日それはどういう意味ですか？2003年1月2日？または、ヨーロッパ：2003年2月1日？年に2桁を使用すると、01/02/03のようにさらに悪化します。

そのため、YYYYMMDDを使用します。これは、日付が常に明確であるため、日付について明確に通信できるようにするための規則です。20030201。（そして、ソートが簡単になります）

（これを整数2000万、3万、200、1として保存しないでください。

t1とt2を、YYYYMMDD形式で記述された2つの時間を表す別個の整数とします。次に、t1 <t2は、t1の後にt2が発生したことを意味します。

DDとMMの最初のフォーマットでは、この順序が失われます。

ISOは、IMO、唯一の賢明な形式です。

言及されていない点の1つは、対話型入力では、この形式により入力を制御できることです。

特定の年と月を知らないと、システムは月の28日、29日、30日、31日のいずれかを知ることができません。対話型入力がその年と月が最初に来ることを指令するとき、日（最後に挿入された）が許容範囲内にあるかどうかをチェックできます。

確かに、質問の大部分は日付形式に関するものでしたが、日付形式はユーザーに提示される形式に従うと主張することができます。

YYYYMMDD注文の日付は、番号を注文するのと同じ方法で、最も重要な部分が最初になります。MMDDYYYYは、「百二十三」を「二十三百」と書くようなものです。

私たちの文化では、MMDDYYYYを自然に理解しています。人間として、時間を意識し、年月がゆっくりと進んでいるからです。私たちは一般に何年かを知っています。年を見ることはめったにないので、私たちはそれを後ろに押します。月は、その重要性を維持するのに十分な速さで切り替わります。他の文化はこれを異なって扱います。世界の多くはDDMMYYYYを好みます。

ソートについても言及しましたが、これを実行する最も有用な理由は、それらを「文字列」として比較することです。はい、26文字のタイムスタンプが同様に順序付けられます。

このような比較は並べ替えに不可欠ですが、一般に2要素の並べ替えには便利です。

私はこれが採用されていないプロジェクトに取り組んできました。はい、プログラマーは（混合した結果で）日付を文字列として比較しようとしました。

プリティフォーマットは、クライアント側または組版用です。

この形式では、文字列のアルファベット順が日付の時系列と同じになります。多くのツールは、たとえばファイルを名前でアルファベット順に並べていますが、ファイル名から任意にフォーマットされた日付を解析してそれらでソートする方法がないため、これは便利です。

それは制限についてです。YEAR、MONTH、およびDAYをパラメーターとして想像してください。YYYYMMDDの形式では、各パラメーターは前のものよりも制限が厳しくなります。

だから1970年に起こったことを検索したいなら、で始まる文字列を検索することでそれをすることができますが"1970*"、どの月だったかを思い出せばあなたは月のように追加できます"197005*"。このように、日付のすべての「パラメーター」は、より具体的な情報を提供します。

これは、特定性の低い情報（"1970*"）から特定性の高い情報（）に移行する唯一の方法"19700523"です。

プログラミングでは、デフォルトの日付形式がYYYYMMDD ...

それは人間が読める形式の入出力形式であり、必ずしもそのように保存されるわけではありません。

すべてのプログラミング言語の3分の1 以上は、英語を主要言語とする国で開発されており、現代のほとんどの言語は何らかの記述の標準に準拠しています。日付の国際標準はISO 8601です。

詳細：（TMI？）

通常、時間の変化に伴い、最初に日が増加し、次に月、最後に年- 時間が経過すると数値が大きくなり、小数の日付（および小数の時間）があるかどうかがわかりやすくなります。人間が数字を見て、一目で別の日付と比較するのは簡単です。

コンピューターは、どの構造を使用するかを気にしません。ほとんどの（すべてではない）コンピューターでは、バイナリロジックが使用されます。ベースeは実際に基数が最も低くなりますが、完全なシーケンスでは最も効率的でも簡単でもありません。

実際の入力と出力の日付の形式は、国によって異なりますし、で設定されているローカライズ、YYYYMMDDは、最も理にかなっているように見えるし、あなたがそれに慣れているものかもしれないが普遍的ではありません今日、またそれはそのようにしたため、過去に最長の時間ですが、今日でも日付にローマ数字が一般的に使用されています。

年を前もって知ることで、1年の日数、1年が受けることができる期間の最大の変動がわかります。おそらく作る-それは最初の翌年には、あなたの入力に同意しなかった場合は、あなたをバックアップする必要がある場合がありますあなたが一日の入力を可能とする、（エラー入力時にチェックするため）に従うために、各月の日数を先行伝えアクセス入力がより困難。また、カレンダー形式に関しても重要です。10進数のスターデートを含むオタクカレンダーも参照してください。

コンピューターに関する限り、UNIXエポック時間を使用する可能性があります。1970年1月1日木曜日の協定世界時（UTC）00:00:00から経過した秒数。正確に86400秒。ユリウス日も参照してください。YYYYMMDD形式は、単にエゴセントリックな人間に好まれます。IAUは、特に指定がない限り、年を365.25日（31.5576ミリ秒）のユリウス年と見なします。

この表現で私が見たもう1つの用途は、日付ごとに4バイトのみを使用して、日付を整数として（つまり、データベースに）格納できることです。YYYYMMDDを使用すると、整数の比較（多くの場合、単一のマシン命令）が、表示された日付の比較と同じ結果になることを意味します。そして、人間が読める程度に適度に印刷します。そして、主流のプログラミング環境では、コードや特別なサポートはまったく必要ありません。

これらのことが日付で行う必要のあるもののほとんどであり、多くのことを行う必要がある場合、この形式には多くの魅力があります。

比較すると、DD / MM / YYYYなどの一般的な形式の日付は、ASCII文字の文字列として10バイトを使用します。YYYYMMDD文字列はそれを8に減らし、「表現の比較は日付の比較と同じ結果になります」という利点を得ますが、それでも文字列ベースの比較は単一の整数比較ではなく文字ごとの比較です。

月がグリーンチーズでできているのと同じ理由：そうではありません。ほとんどの場合、デフォルトの形式は何らかのローカライズされた文字列です。ISO形式が使用されることもありますが、通常は読みやすくするためにダッシュを使用します。YYYYMMDD（または%Y%m%dでstrftime業界用語）めったにデフォルトではありません。公平を期すために、私はそれを見たことがあると確信していますが、今の例は考えられません。

Unix日付（GNUコアユーティリティ）

date

出力：

Wed Sep 26 22:20:57 CEST 2018

Python

import time
print(time.ctime())

出力：

Wed Sep 26 22:27:20 2018

C

#include <stdio.h>
#include <time.h>

int main () {
   time_t curtime;

   time(&curtime);
   printf(ctime(&curtime));
   return(0);
}

出力：

Wed Sep 26 22:40:01 2018

C ++

#include <ctime>
#include <iostream>

int main()
{
    std::time_t result = std::time(nullptr);
    std::cout << std::ctime(&result);
}

出力：

Wed Sep 26 22:51:22 2018

Javascript

current_date = new Date ( );
current_date;

出力：

Wed Sep 26 2018 23:15:22 GMT+0200 (CEST)

SQLite

SELECT date('now');

出力：

2018-09-26

LibreOffice Calc

数字

OnlyOffice

Python + numpy

import numpy as np
pd.datetime64('now')

出力：

numpy.datetime64('2018-09-26T21:31:55')

Python +パンダ

import pandas as pd
pd.Timestamp('now', unit='s')

出力：

Timestamp('2018-09-26 21:47:01.277114153')

ソフトウェア工学

apport.log

ERROR: apport (pid 9742) Fri Sep 28 17:39:44 2018: called for pid 1534, signal 6, core limit 0, dump mode 2

alternatives.log

update-alternatives 2018-05-08 15:14:24: run with --quiet --install /usr/bin/awk awk /usr/bin/mawk 5 --slave /usr/share/man/man1/awk.1.gz awk.1.gz /usr/share/man/man1/mawk.1.gz --slave /usr/bin/nawk nawk /usr/bin/mawk --slave /usr/share/man/man1/nawk.1.gz nawk.1.gz /usr/share/man/man1/mawk.1.gz

cups / access.log

localhost - - [28/Sep/2018:16:41:58 +0200] "POST / HTTP/1.1" 200 360 Create-Printer-Subscriptions successful-ok

syslog

Sep 28 16:41:46 pop-os rsyslogd:  [origin software="rsyslogd" swVersion="8.32.0" x-pid="946" x-info="http://www.rsyslog.com"] rsyslogd was HUPed

これまで言及されていない追加の利点は、望ましい量子化（同じ一般的な値の範囲に属するものとして正確な値を割り当てる）が比較的簡単で高速な単一操作であることです。

販売の合計や数など、今日のイベントを要約したレポートを作成しているとします。セールの日付と時刻はYYYYMMDDHHMISSとして保存されます。左端の8文字（文字列の場合）または整数を1,000,000で除算（つまり下限）するだけで、日時をセール当日まで減らすことができます。

同様に、月の売上が必要な場合は、左端の6桁のみを保持するか、100,000,000で除算します

もちろん、任意の文字列操作が可能であると主張できます。「12-25-2018 12:34 pm」の販売の日時を部分文字列化し、複数回操作して月と年を取得できます。数値形式では、122520181234を分割、修正、乗算、さらに分割し、最終的に月と年を生成することもできます。しかし、コードを書く、読む、維持する、理解するのは本当に難しいでしょう

また、洗練されたデータベースオプティマイザーでさえ、日付形式がMM / DD / YYYYであるが、分割して結合された場合、where句の列のインデックスを使用できない場合があります。それに比べて、YYYYMMDD表現を保存し、2018年12月が必要な場合は、ilkのwhere句dateasstring LIKE '201812%'またはdateasint BETWEEN 20181200 and 20181299インデックスを簡単に使用できるものになります

したがって、日付に専用のデータ型がなく、文字列/数値表現が唯一の選択肢であり、左側の最長間隔から最短の間隔のいくつかの表現で時間を使用して保存する場合権利には、理解、操作、保管、検索、およびコードの保守を容易にするためのいくつかの利点があります