Bunun böyle olmasının herhangi bir mühendislik sebebi var mı? Bir "YIL" bir "AY" dan daha spesifik olduğu için bir RDBMS durumunda performans ile ilgisi olduğunu merak ediyordum, örneğin: sadece bir yıl 2000 var, ancak her yıl "Ocak", bu, ilk önce bir şeyi filtrelemek / sıralamak için daha kolay / daha hızlı olur ve bu nedenle yılın ilk gelmesi.

Ama bunun gerçekten mantıklı olup olmadığını bilmiyorum ... Herhangi bir sebep var mı?

Bu şekilde, tarihler varsayılan sıralama kurallarını (örneğin, sözlük sıralama ) kullanarak kolayca dizeler olarak sıralanabilir .

Bu nedenle hem ay hem de gün iki basamak kullanılarak belirtilir (gerekirse bir sıfır eklenir).

Aslında ISO 8601 tarafından tanımlanan tarih biçimlerinden biridir . Bu standart ayrıca, 2015-03-27T15:26:40Zdizeler olarak da sıralanabilen tarih ve saat biçimini tanımlar .

Bununla birlikte, YYYYMMDD'nin, dizeyi bir tam sayı olarak ayrıştırmasını ve yine de tamsayılarda varsayılan sıralamayı kullanmasını kolaylaştırarak (alt dizeler veya karakter değiştirmeleri olmadan) kolayca mümkün kılmanın ek bir yararı vardır .

Henüz bahsedilmedi, ancak YYYY içindeki siparişleri hızlı bir şekilde parlatıyorsunuz. Bu zaten bin yıl, yüzyıl, yıl, yıl. Başka bir deyişle, YYYY zaten en uzun dönemden en kısa süreye sipariş edilir. Aynı şey MM ve DD için de geçerli, sayı sistemi böyle çalışıyor.

Dolayısıyla, alanlar arasındaki sırayı alanların içindeki sırayla tutarlı tutmak için tek seçenek YYYYMMDD'dir.

Zahbaz ve Arseni Mourzenko'nun belirttiği gibi, YYYYMMDD formatları kolayca sıralanır. Bu şanslı bir tesadüf değil, ilk önce tarlaları en uzun süre koymak (ve uzunluğu sabit tutmak; burada bir Y10K problemi ortaya koyuyoruz) doğrudan bir sonucudur.)

Herhangi bir sebep var mı?

Evet. Bu yazılım parçaları ISO 8601'i kullanacak .

ISO 8601'in diğer tarih biçimlerine göre birçok avantajı vardır:

• Belirli bir belgeye sahip bir standart :)
• Belirgin değil. GG / aa / yyyy ve gg / aa / yyyy 13. günü geçmedikçe kafa karıştırıcı olabilir.
• Sözcükbilimsel olarak artan zaman sırasına göre sıralanır, bu nedenle özel bir tarih sıralama mantığı gerekmez. Bu, özellikle sözlükbilimsel sayı sıralamasının kafa karıştırıcı olduğu (örneğin 1_file, 10_file, 2_file) dosya isimlerinde kullanışlıdır .
• 4 basamaklı yıl ve sıfır yastıklı ay ve yıl zorunludur. Bu, 2000 yılı sorununu ve diğer belirsizliklerden kaçınır.

Neden ISO 8601'in ilk sırada yer aldığına gelince , insanlar tarih / formatları ülkeler / sistemler arasında veri takas ederken belirsiz ve kafa karıştırıcı buluyorlardı ve belirsiz bir şeye ihtiyaçları vardı.

Gerekçe için şartnamenin giriş bölümüne bakınız .

Bu alandaki ISO Tavsiyeleri ve Standartları 1971'den beri mevcut olmasına rağmen, farklı ülkelerde tarihlerin ve saatlerin farklı sayısal temsil biçimleri ortak kullanımdadır. Bu temsillerin ulusal sınırlar arasında değiştirildiği yerlerde, sayıların öneminin yanlış yorumlanması meydana gelebilir, bu da karışıklığa ve diğer sonuçta ortaya çıkan hata veya kayıplara neden olabilir. Bu Uluslararası Standardın amacı, yanlış yorumlanma riskini ortadan kaldırmak ve karışıklık ve sonuçlarından kaçınmaktır.

...

Bu Uluslararası Standart, günün tarihi ve saati için en sık kullanılan ifadeleri ve önceki Uluslararası Standartlardan gelen temsillerini korur ve uygulamada kullanılan bazı yeni ifadeler için benzersiz temsiller sağlar. Bilgi alışverişinde, özellikle veri işleme sistemleri ve ilgili ekipman arasında uygulanması, yanlış yorumlamadan kaynaklanan hataları ve bunların ürettiği maliyetleri ortadan kaldıracaktır. Bu Uluslararası Standardın tanıtımı sadece uluslararası sınırlar arasında değişimi kolaylaştırmakla kalmayacak, aynı zamanda yazılımın taşınabilirliğini de artıracak ve bir organizasyon içinde olduğu kadar kurumlar arasındaki iletişim sorunlarını da kolaylaştıracaktır.

Standart, sınırlayıcı kullanımını en aza indirerek “temel” varyasyonları tanımlar. Yani, YYYYMMDDbir temel genişletilmiş biçimine alternatif YYYY-MM-DD.

Çünkü bunu yapmanın diğer tüm yolları belirsizdir.

01.02.2003 Bu ne anlama geliyor? İkinci Ocak 2003? Veya Avrupa'da: 1 Şubat 2003? 01/02/03 olarak yıl için iki rakam kullanırsanız daha da kötüleşir.

Bu nedenle YYYYMMDD'yi kullanıyorsunuz, tarihler hakkında net bir şekilde iletişim kurmamızı sağlayan sözleşme, 20030201 tarihinin her zaman açık olduğu gibi. (ve sıralamayı kolaylaştırır)

(Şimdi bunu 20 milyon 30 bin 2 yüz ve 1 tamsayısı olarak saklamayınız.

T1 ve t2'nin YYYYMMDD formatında iki kere yazılan farklı tam sayılar olmasına izin verin. Daha sonra t1 <t2, t2'nin t1'den sonra gerçekleştiğini belirtir.

DD ve MM ilk biçimlendirmesiyle bu siparişi kaybedersiniz.

ISO, IMO, tek mantıklı format.

Bahsedilmeyen noktalardan biri, etkileşimli girdilerde, bu formatın girişi kontrol etmesine izin verdiğidir.

Sistem, bir ayın belirli bir yılı ve ayı bilmeden 28, 29, 30 veya 31 günü olup olmadığını bilemez. Etkileşimli giriş o yıl ve ayın başına geldiğinde, en son eklenen günün izin verilen aralıkta olup olmadığını kontrol edebilir.

Kabul edilirse, soru büyük ölçüde tarih biçimiyle ilgiliydi, ancak tarih biçiminin kullanıcıya sunulan biçimlendirmeyi takip ettiği söylenebilir.

YYYYMMDD siparişleri, sipariş verdiğiniz şekilde düzenlenir: ilk önce en önemli kısım. MMDDYYYY, "yüz yirmi üç" kelimesini "yirmi yüz" olarak yazmak gibi bir şey olur.

Kültürümüzde MMDDYYYY'nin doğal bir anlayışına sahibiz, çünkü insanlar olarak zaman farkındalığımız var ve yıllar yavaş ilerliyor. Genellikle hangi yıl olduğunu biliyoruz. Yılı görmek nadiren önemlidir, bu yüzden arkaya doğru iteriz. Aylar önemini koruyacak kadar hızlı değişiyor. Diğer kültürler bunu farklı şekilde ele alır. Dünyanın çoğu DDMMYYYY'yi tercih ediyor.

Sıralamadan bahsedilmiştir, ancak bugüne kadar yapmak için en faydalı neden, bunları "dizge" olarak karşılaştırmaktır ve evet, aynı şekilde 26 karakterli bir zaman damgası da sipariş edilir.

Bu tür karşılaştırmaların sıralama için zorunlu olduğunu biliyorum, ancak genellikle 2 elemanlı sıralama için kullanışlıdır.

Bunun kabul edilmediği projeler üzerinde çalıştım ve evet, programcılar tarihleri ​​karışık dizelerle karşılaştırmaya çalıştı.

Güzel biçimlendirme müşteri tarafında veya dizgi için.

Bu biçim, dizelerin alfabetik sıralamasını tarihlerin kronolojik sırasına benzer yapar. Bu yararlıdır, çünkü birçok araç örneğin dosyaların adlarına göre alfabetik olarak sıralanmasını sağlar, ancak dosya adlarından rasgele biçimlendirilmiş tarihleri ​​ayrıştırmanın ve bunlara göre sıralamanın bir yolunu yoktur.

Kısıtlılık hakkında. YAR, AY ve GÜN'ü parametre olarak düşünün, YYYYMMDD biçiminde her parametre öncekinden daha kısıtlayıcıdır.

Böylece, 1970'de olan bir şeyi aramak "1970*"istiyorsanız, baştan başlayarak bir dize arayarak yapabilirsiniz , ancak hangi ayın olduğunu hatırlarsanız, ayı gibi ekleyebilirsiniz "197005*". Bu şekilde, tarihin her "parametresi" size daha ayrıntılı bilgi verir.

Daha az spesifik bilgi ( "1970*") 'den daha spesifik bilgi' ye ( "19700523") geçmek için tek yol bu .

Neden programlamada varsayılan tarih formatı YYYYMMDD ...

Giriş ve çıkış için okunabilir bir formattır, mutlaka bu şekilde depolanması gerekmez.

Tüm programlama dillerinin üçte birinden fazlası İngilizce olan ve ana dil olarak İngilizce olan bir ülkede geliştirildi ve modern olanların çoğu bir tanım standardına uyuyor - tarihler için uluslararası standart ISO 8601 .

Daha fazla bilgi: (TMI?)

Zaman değiştikçe, genellikle ileriye doğru, günler ilk önce artar, sonra aylar, son olarak yıllar - ondalık tarihler olup olmadığımızı (ve ondalık süremiz ) anlamamız daha kolay olabilir - zaman geçtikçe sayı büyür. İnsanların sayıya bakması ve bir bakışta başka bir tarihle karşılaştırması daha kolay.

Bilgisayar hangi yapıyı kullanmak istediğinizi umursamıyor ve çoğu (ama hepsinde değil ) bilgisayarlarında ikili mantık kullanılıyor - e tabanı aslında en düşük yarıçap ekonomisine sahip ancak tam bir sıra için en verimli ve en kolay değil .

Tarihler için gerçek girdi ve çıktı biçimi ülkeye göre değişir ve yerelleştirmeye göre ayarlanır , YYYYMMDD bugün için en mantıklı olanıdır ve alışkın olduğunuz şey evrensel görünmeyebilir , geçmişte de öyle değildi . En uzun süre henüz bugün bile Romen rakamları vardır yaygın tarihleri için kullanılan .

Önümüzdeki yılı bilmek, bir yıl içindeki gün sayısını, bir yıl boyunca sürebilecek en büyük değişimin olduğunu söyler. Her aydaki izlemeniz gereken gün sayısını (giriş sırasındaki hata kontrolü için) önceden bildirir, bir sonraki yıl girişinizi kabul etmediyse ilk gün girişine izin vermek sizi destekleyebilir - muhtemelen erişilebilir girişi zorlaştırır . Takvim formatı açısından da önemi vardır . Ayrıca ondalık yıldız tarihleriyle geek takvimine bakın .

Bilgisayar söz konusu olduğunda, UNIX Epoch zamanını , 00:00:00 'den beri geçen saniye sayısını, her gün içeriyormuş gibi muamele ettiği 1 Ocak 1970, Perşembe, UTC) kullanması muhtemeldir. tam olarak 86400 saniye. Jülyen gününe de bakınız . YYYYMMDD formatı, çok merkezli insanlar tarafından basitçe tercih edilir, IAU, aksi belirtilmediği sürece , bir yılı 365.25 günlük (31.5576 milyon saniye) Julian yılı olarak görür.

Bu gösterim için gördüğüm diğer bir kullanım, tarihleri ​​yalnızca tarih başına 4 bayt kullanarak tam sayılar olarak (yani bir veritabanında) saklayabilmenizdir. YYYYMMDD kullanmak, daha sonra tamsayı karşılaştırmalarının (genellikle tek bir makine talimatı), temsil edilen tarihte yapılan karşılaştırmalarla aynı sonuca sahip olduğu anlamına gelir. Ve orta derecede insan tarafından kolayca basılabilir. Ve bunların hiçbiri, herhangi bir ana programlama ortamında, herhangi bir kod veya özel bir destek gerektirmez.

Bu şeyler, tarihlerle yapmanız gerekenlerin çoğunu oluşturuyorsa ve çoğunu yapmanız gerekiyorsa, bu biçimin çok çekiciliği vardır.

Buna karşılık, DD / MM / YYYY gibi ortak biçimlerde tarihler, ASCII karakterlerinin dizeleri olarak 10 bayt alır. YYYYMMDD dizeleri bunu 8'e düşürür ve "gösterimleri karşılaştırmak tarihleri ​​karşılaştırmakla aynı sonucu verir" avantajını elde eder, ancak o zaman bile dize tabanlı karşılaştırma, tek bir tamsayı karşılaştırması yerine karakter karakterdir.

Ayın yeşil peynirden yapılmış olmasının sebebi aynı: değil. Çoğu durumda, varsayılan biçim bir tür yerelleştirilmiş dizedir. Bazen ISO formatı kullanılır, ancak daha iyi okunabilirlik için genellikle kısa çizgilerle kullanılır. YYYYMMDD(veya %Y%m%diçinde strftimetabiriyle) nadiren varsayılan değerdir. Adil olmak gerekirse, onu gördüğüme eminim ama şu anda bir örnek düşünemiyorum.

Unix tarihi (GNU çekirdek yardımcı programları)

date

Çıktı:

Wed Sep 26 22:20:57 CEST 2018

piton

import time
print(time.ctime())

çıktı:

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);
}

Çıktı:

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);
}

Çıktı:

Wed Sep 26 22:51:22 2018

JavaScript

current_date = new Date ( );
current_date;

Çıktı:

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

SQLite

SELECT date('now');

Çıktı:

2018-09-26

LibreOffice Calc

Gnumeric

OnlyOffice

Python + numpy

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

Çıktı:

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

Python + pandalar

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

Çıktı:

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

Yazılım Mühendisliği

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

bardaklar / 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

Şimdiye kadar belirtilmeyen ilave bir avantaj, arzu edilen nicelleştirmenin (aynı genel değer aralığına ait kesin bir değer atamak) nispeten kolay ve hızlı bir tek işlem olmasıdır.

Satışların toplamı ve sayısı gibi bugünkü olayları özetleyen bir rapor yazdığınızı varsayalım. Satış tarihi ve saati YYYYMMDDHHMISS olarak saklanır, tarihinizi satış gününe düşürmek için en soldaki 8 karakteri (bir dizge ise) veya tam sayıdaki bölmeyi (yani kat) 1.000.000 değerinde tutmanız gerekir.

Benzer şekilde, ayın satışını istiyorsanız, yalnızca en soldaki 6 haneyi tutarsanız veya 100.000.000’e böldüyseniz

Elbette, herhangi bir dizi manipülasyonunun mümkün olduğunu iddia edebilirsiniz, "12-25-2018 12:34" satışının tarih ve saatini ay ve yılı elde etmek için birçok kez bastırabilir ve değiştirebilir. Sayısal formda 122520181234 bölünmüş ve modellenmiş ve çarpılmış ve biraz daha bölünmüş olabilir ve sonunda bir ay ve bir yıl da üretebilir .. .. ama kodun yazılması, okunması, bakımı ve anlaşılması zor olurdu.

Ayrıca, karmaşık veritabanı en iyi duruma getiricileri bile, tarih biçimi MM / DD / YYYY ise, ancak kesilip tekrar birleştirildiyse, bir sütun için bir dizindeki bir dizini kullanamayabilir. Buna karşılık, bir YYYYMMDD temsilini saklamak ve Aralık 2018'i istemek, ilk dateasstring LIKE '201812%'ya da dateasint BETWEEN 20181200 and 20181299- bir dizinin kolayca kullanılabileceği bir maddeye yol açar.

Böylece, tarihler için özel bir veri türü yoksa ve dize / sayısal gösterim tek seçimdi, en soldaki en kısa aralıktaki en uzun aralıktaki en kısa aralıktaki gösterimi kullanarak zamanları kullanmak ve saklamak hakkın anlaşılma, manipülasyon, depolama, geri alma ve kod bakım kolaylığı için oldukça az yararı var