Чи є інженерна причина, чому це так? Мені було цікаво у випадку з RDBMS, що це має щось спільне з продуктивністю, оскільки "РІК" є більш конкретним, ніж "МІСЯЦЬ", наприклад: у вас є лише 2000 рік, але кожен рік маєте "січень", що полегшило б / швидше фільтрувати / сортувати щось спочатку за роком, і саме тому рік приходить першим.

Але я не знаю, чи це насправді має сенс ... Чи є взагалі якась причина?

Таким чином, дати можна легко сортувати як рядки, використовуючи правила сортування за замовчуванням (тобто лексикографічне сортування ).

З цього приводу і місяць, і день визначаються двома цифрами (додаючи нульовий нуль, якщо потрібно).

Фактично це один з форматів дати, визначений ISO 8601 . Цей стандарт також визначає формат дати та часу 2015-03-27T15:26:40Z, який також можна сортувати як рядки.

Однак YYYYMMDD має додаткову перевагу, завдяки чому легко (без підрядів чи заміни символів) розбирати рядок як ціле число, та все ж використовувати замовлення за замовчуванням на цілі числа.

Ще не згадано, але ви швидко промальовуєте замовлення всередині РРРР. Це вже тисячоліття, століття, десятиліття, роки. Тобто, РРРР вже впорядковано від найдовшого до найкоротшого періоду. Те саме стосується MM та DD, саме так працює система числення.

Отже, щоб зберегти порядок між полями узгодженим із порядком у полях, єдиний варіант - YYYYMMDD

Як зауважили zahbaz та Арсеній Мурзенко, формати YYYYMMDD легко сортуються. Це не випадковий збіг обставин, це прямий наслідок того, що на перше місце покладіть поля на найдовшу тривалість (і дотримуйтесь фіксовану довжину; ми вводимо тут проблему Y10K.)

Чи взагалі є якась причина?

Так. Ці програми будуть використовувати ISO 8601 .

ISO 8601 має ряд переваг перед іншими форматами дати:

• Це стандарт із специфічним документом :)
• Це однозначно. mm / dd / yyyy та dd / mm / yyyy можуть бути заплутаними, якщо не минуло 13-го дня.
• Він лексикографічно впорядковується у порядку зростання, тому не потрібна спеціальна логіка сортування дати. Це особливо корисно для імен файлів, де лексикографічне сортування чисел часто плутає (наприклад 1_file, 10_file, 2_file).
• Він передбачає чотиризначний рік та місяць та рік із зануренням. Це дозволяє уникнути проблеми 2000 року та інших неясностей.

Що стосується того, чому ISO 8601 існує в першу чергу, це тому, що люди знаходили формати дати неоднозначними та заплутаними під час обміну даними між країнами / системами, і їм було потрібно щось однозначне.

Для обґрунтування див . Вступ специфікації .

Хоча рекомендації та стандарти ISO в цій галузі доступні з 1971 року, різні форми числового представлення дат і часу були загальноприйнятими для різних країн. Якщо подібні уявлення міняються через національні кордони, може статися неправильне тлумачення значення числівників, що призводить до плутанини та інших наслідкових помилок чи втрат. Метою цього Міжнародного стандарту є усунення ризику неправильного тлумачення та уникнення плутанини та її наслідків.

...

Цей Міжнародний стандарт зберігає найпоширеніші вирази для дати та часу дня та їх представлення з попередніх Міжнародних стандартів та надає унікальні подання для деяких нових виразів, що використовуються на практиці. Застосування його в обміні інформацією, особливо між системами обробки даних та пов'язаним з цим обладнанням, усуне помилки, що виникають внаслідок неправильного тлумачення, та витрат, які вони створюють. Просування цього Міжнародного стандарту не тільки сприятиме обміну через міжнародні кордони, але також покращить портативність програмного забезпечення та полегшить проблеми спілкування в організації, а також між організаціями.

Стандарт визначає "основні" варіанти як мінімізацію використання роздільників. Отже, YYYYMMDDє базовою альтернативою розширеному формату YYYY-MM-DD.

Це тому, що всі інші способи зробити це неоднозначно.

01.02.2003, що це означає? Другий січень 2003 року? Або в Європі: 1 лютого 2003 року? Це стає ще гірше, якщо ви користуєтесь двома цифрами за рік, як 01.02.03.

Ось чому ви використовуєте YYYYMMDD, це умова, яка дозволяє нам чітко спілкуватися про дати, 20030201 як дата завжди зрозуміла. (і це полегшує сортування)

(Тепер не продовжуйте зберігати це як цілі 20 мільйонів 30 тисяч 2 сотні і 1. будь ласка, добре? Досить будь ласка?)

Нехай t1 і t2 є цілими цілими числами, які представляють два рази, записані у форматі YYYYMMDD. Тоді t1 <t2 означає, що t2 стався після t1.

Ви втрачаєте це замовлення при першому форматуванні DD та MM.

ISO - ІМО - єдиний розумний формат.

Один момент, який не згадується, - це те, що на інтерактивних входах цей формат дозволяє контролювати введення.

Система не може знати, чи є в місяці 28, 29, 30 або 31 день, не знаючи конкретного року та місяця. Коли інтерактивне введення вказує на перший рік та місяць, він може перевірити, чи день (вставлений останній) знаходиться в дозволеному діапазоні.

Звичайно, питання стосувалося в основному формату дати, але можна стверджувати, що формат дати відповідає форматуванню, представленому користувачеві.

YYYYMMDD замовлення датується так само, як ви замовляєте номери: найзначніша частина спочатку. MMDDYYYY було б як написати "сто двадцять три" як "двадцять і сто три".

У нашій культурі ми природно розуміємо MMDDYYYY, оскільки ми, як люди, усвідомлюємо час, і роки прогресують повільно. Ми взагалі знаємо, який це рік. Бачити рік рідко має значення, тому ми відсуваємо його до спини. Місяці змінюються досить швидко, щоб зберегти свою важливість. Інші культури справляються з цим неоднаково. Більшість країн віддають перевагу DDMMYYYY.

Впорядкування було згадано, але, безумовно, найбільш корисною причиною цього є порівняння їх як "рядків", і так, часова мітка на 26 символів впорядковується аналогічно.

Мені відомо, що такі порівняння мають важливе значення для сортування, але це, як правило, корисно для 2-х елементів елементів.

Я працював над проектами, де це не було прийнято, і так, програмісти намагалися (зі змішаними результатами) порівняти дати як рядки.

Досить форматування призначене для клієнта або набору тексту.

Цей формат робить алфавітний порядок рядків ідентичним хронологічному порядку дат. Це корисно, оскільки багато інструментів забезпечують алфавітне впорядкування, наприклад, файлів за іменем, але ніяк не можна проаналізувати довільно відформатовані дати з імен файлів та сортувати їх.

Йдеться про обмеженість. Уявіть як параметри YEAR, MONTH та DAY, у форматі YYYYMMDD кожен параметр є більш обмежуючим, ніж попередній.

Отже, якщо ви хочете шукати щось, що трапилося в 1970 році, ви можете зробити це шляхом пошуку рядка, починаючи з "1970*", але якщо ви пам’ятаєте, з якого місяця ви можете додати місяць, як "197005*". Таким чином, кожен "параметр" дати дає вам більш конкретну інформацію.

Це єдиний спосіб перейти від менш конкретної інформації ( "1970*") до більш конкретної інформації ( "19700523").

Чому в програмуванні формат дати за замовчуванням - YYYYMMDD ...

Це людський читаний формат для введення та виведення, він не обов'язково зберігається таким чином.

Більше третини всіх мов програмування були розроблені в країні, де англійською мовою є основною мовою, а більшість сучасних дотримуються стандарту деякого опису - міжнародний стандарт на дати - ISO 8601 .

Більше інформації: (TMI?)

З часом, як правило, вперед, приріст днів спочатку, потім місяці, останні роки - це може бути простіше зрозуміти, якби у нас були десяткові дати (і десятковий час ) - з часом час число збільшується. Людям просто простіше подивитися на номер і порівняти його з іншою датою.

Комп'ютеру не важливо, яку структуру ви хочете використовувати, і в більшості (але не на всіх ) комп'ютерах використовується двійкова логіка - база e насправді має найнижчу економію, але не є найефективнішою та найпростішою для повної послідовності .

Фактичний формат введення та виведення дат змінюється залежно від країни та встановлюється локалізацією , тоді як YYYYMMDD може здатися, що це має найбільше сенс і бути тим, до чого ви звикли, не є універсальним сьогодні, і не було так раніше в минулому довше часу, але навіть сьогодні римські цифри які зазвичай використовуються для дат .

Знаючи рік наперед, ви повідомляєте кількість днів у році, найбільша різниця в тривалості, яку може пройти рік. Він повідомляє вам про кількість днів у кожному місяці, які слід слідкувати (для перевірки помилок під час вступу), дозволяючи ввести перший день, можливо, доведеться створити резервну копію, якщо наступний рік не погодився з вашим вкладом - можливо, ускладнюючи доступну інформацію . Це також має важливе значення щодо формату календаря . Дивіться також календар виглядів з його десятковими зірками.

Що стосується комп'ютера, то, швидше за все, використовується час UNIX Epoch , кількість секунд, що минули з 00:00:00 Універсальний координований час (UTC), четвер, 1 січня 1970 року, де кожен день трактується так, ніби він містить рівно 86400 секунд. Дивіться також День Юліана . Формат YYYYMMDD просто відданий перевагу егоцентричним людям; IAU вважає рік юліанським роком 365,25 днів (31,5576 мільйонів секунд), якщо не вказано інше.

Ще одне використання, яке я бачив для цього представлення, полягає в тому, що ви можете зберігати дати як цілі числа (тобто в базі даних), використовуючи лише 4 байти на дату. Використання YYYYMMDD означає, що цілісні порівняння (часто це одна інструкція з машини) мають той же результат, що і порівняння на представлену дату. І він друкується помірно по-людськи. І нічого з цього взагалі не вимагає коду чи спеціальної підтримки в будь-якому середовищі програмного забезпечення.

Якщо ці речі є більшістю того, що вам потрібно зробити з датами, і вам потрібно зробити це багато, то цей формат має велику привабливість.

Для порівняння, дати в таких форматах, як DD / MM / YYYY, приймають 10 байт як рядки символів ASCII. Рядки YYYYMMDD зменшують це до 8, а отримання "порівняння представлень має такий самий результат, як і порівняння дат", але навіть тоді порівняння на основі рядків є символом за символом, а не єдиним цілим числом порівняння.

З тієї ж причини, що Місяць зроблений із зеленого сиру: це не так. У більшості випадків формат за замовчуванням - це якийсь локалізований рядок. Іноді використовується формат ISO, але зазвичай з тире для кращої читабельності. YYYYMMDD(Або %Y%m%dв strftimeпросторіччі) рідко використовується за умовчанням. Чесно кажучи, я впевнений, що це я бачив, але зараз не можу придумати приклад.

Дата Unix (основні утиліти GNU)

date

Вихід:

Wed Sep 26 22:20:57 CEST 2018

Пітон

import time
print(time.ctime())

вихід:

Wed Sep 26 22:27:20 2018

С

#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

Гнумерний

ТількиОфіс

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

альтернативи.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

чашки / 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 цифр або ділите на 100000000

Звичайно, ви можете стверджувати, що можливі будь-які маніпуляції з рядками, а дата дати продажу "12-25-2018 12:34 вечора" може бути підредагована і маніпульована кілька разів, щоб отримати місяць і рік. У числовій формі 122520181234 можна було б розділити і модифікувати, помножити та розділити ще кілька, а в кінцевому підсумку також створити місяць і рік .. .. але код було б дуже важко написати, прочитати, підтримувати та розуміти ..

І навіть складні оптимізатори баз даних можуть не в змозі використовувати індекс у стовпці для пункту «де», якщо форма дати склала MM / DD / РРРР, але зібрана і зведена разом. Для порівняння, зберігання представлення YYYYMMDD та бажання грудня 2018 року призводять до того, де можуть бути використані пункти ilk dateasstring LIKE '201812%'або dateasint BETWEEN 20181200 and 20181299- щось, що може бути індексом

Таким чином, якщо не було виділеного типу даних для дат і подання рядків / числових даних, це був єдиний вибір, використання та зберігання часу в деякому поданні найдовшого інтервалу "зліва-зліва" до "найкоротшого інтервалу" на " право має досить багато переваг для зручності розуміння, маніпуляцій, зберігання, пошуку та обслуговування коду