Apakah ada alasan teknis mengapa, dalam pemrograman, format tanggal default adalah YYYYMMDD dan bukan yang lain?


118

Apakah ada alasan teknis mengapa seperti itu? Saya bertanya-tanya dalam kasus RDBMS bahwa itu ada hubungannya dengan kinerja, karena "TAHUN" lebih spesifik daripada "BULAN", misalnya: Anda hanya memiliki satu tahun 2000, tetapi setiap tahun memiliki "Januari", yang akan membuatnya lebih mudah / lebih cepat untuk memfilter / menyortir sesuatu berdasarkan tahun pertama, dan itulah sebabnya tahun itu datang lebih dulu.

Tetapi saya tidak tahu apakah itu benar-benar masuk akal ... Apakah ada alasan?


14
@IMil Kita mungkin tidak menyukainya, tetapi seringkali mereka disimpan sebagai string.
Honza Brabec

14
@candied_orange Itu akan aneh, terutama dalam hal tanggal.
glglgl


19
Sebagai catatan, format ini tidak terlalu asing. Misalnya, dalam bahasa Hongaria (dan mungkin beberapa yang lain juga) YYYY. MM. DD. adalah format tanggal tertulis standar, dan sudah lama ada sebelum komputer.
Neinstein

31
Dalam pemrograman, format tanggal default adalah "YYYYMMDD"? Akan lebih baik jika itu benar, tapi itu pasti tidak terjadi di mana-mana. RFC 822 dan RFC 850, serta ANSI C asctime, masih banyak digunakan di banyak tempat. Sangat menyenangkan bahwa RFC 3339 dan ISO 8601 secara bertahap mengganti format yang lebih lama, dan mereka pasti apa yang harus digunakan di masa depan. Secara umum, saya akan mengatakan bentuk dasar ISO 8601 (YYYYMMDD polos tanpa karakter pemisah) sebenarnya kurang umum daripada beberapa bentuk lain, seperti YYYY-MM-DD.
Daniel Pryden

Jawaban:


386

Dengan cara ini, tanggal dapat dengan mudah diurutkan sebagai string menggunakan aturan penyortiran default (yaitu penyortiran lexicographical ).

Ini juga mengapa bulan dan hari ditentukan menggunakan dua digit (menambahkan nol di depan jika diperlukan).

Bahkan itu adalah salah satu format tanggal yang ditentukan oleh ISO 8601 . Standar itu juga mendefinisikan format tanggal dan waktu 2015-03-27T15:26:40Z, yang juga dapat disortir sebagai string.

Namun, YYYYMMDD memiliki manfaat tambahan untuk memungkinkannya dengan mudah (tanpa penggantian substring atau karakter), parsing string sebagai integer, dan masih menggunakan pemesanan default pada integer.


90
@ lucaswxp: Jika Anda menulis perbandingan kasus khusus untuk string mengikuti skema tertentu, Anda tentu saja dapat menjadikannya sebagai barok seperti yang Anda inginkan. Masalahnya di sini adalah bahwa skema dirancang sedemikian rupa sehingga urutan leksikal (serta urutan sadar nomor leksikal) juga urutan logis, sehingga tidak perlu untuk menyesuaikan.
Deduplicator

19
@ lucaswxp String tanggal Anda mungkin tidak ada dalam memori. Contoh praktis: Anda memiliki file csv yang sudah diurutkan berdasarkan tanggal ISO dan jutaan + baris per tahun. Dan Anda ingin mengembalikan hanya baris di antara tanggal tertentu. Anda dapat membaca file baris demi baris (baris demi baris) hingga Anda mencapai tanggal pertama Anda, kemudian memuat baris ke dalam memori sampai Anda mencapai tanggal terakhir Anda. Anda dapat melewati sisa file. Tetapi jika Anda menyimpan tanggal sebagai format lain, atau disortir berdasarkan tahun saja, Anda harus membaca catatan sepanjang tahun sebelum menutup file.
Tom A. Vibeto

48
Perhatikan bahwa tanda hubung adalah opsional di ISO 8601, jadi YYYYMMDD adalah ISO 8601.
Martin Ba

32
@ Beneno Sebuah proposal telah dibuat untuk menyelesaikan masalah Y10K. Jika kita masih menggunakan era yang sama, kita akan pergi ke AYYYYYMMDD hingga Y100K, yang akan menjadi BYYYYYYMMDD, CYYYYYYYMMDD, DYYYYYYYYMMDD, EYYYYYYYYYMMDD. Awalan alfa terkemuka ini memastikan urutan pengurutan yang benar (asalkan "A0YYYY ..." dll. Adalah representasi yang tidak valid jika masih ada YYYY ... tanggal yang digunakan). Di beberapa titik ketika jumlah digit tahun dapat dibagi tiga, kita akan mulai menambahkan tiga digit setiap kali kita mengubah awalan alfa, untuk memastikan kita tidak kehabisan huruf sebelum kematian panas alam semesta.
Monty Harder

35
Penting untuk dicatat bahwa dengan format ini, pengurutan tidak hanya "lebih mudah." Jenis leksikal (berdasarkan karakter) menjadi setara dengan jenis temporal, yang berarti Anda dapat mengurutkan sementara tanpa penguraian .
jpmc26

135

Belum disebutkan, tetapi Anda dengan cepat mengabaikan pesanan di dalam YYYY. Itu sudah ribuan tahun, berabad-abad, puluhan tahun, bertahun-tahun. Artinya, YYYY sudah dipesan dari periode terpanjang ke periode terpendek. Hal yang sama berlaku untuk MM dan DD, begitulah sistem bilangan bekerja.

Jadi untuk menjaga urutan antar bidang konsisten dengan urutan dalam bidang, satu-satunya pilihan adalah YYYYMMDD.

Seperti dicatat zahbaz dan Arseni Mourzenko, format YYYYMMDD mudah disortir. Itu bukan kebetulan yang beruntung, itu konsekuensi langsung dari menempatkan bidang untuk durasi terlama pertama (dan menjaga panjang tetap; kami memperkenalkan masalah Y10K di sini.)


34
Meskipun Anda mungkin bercanda, kode ini mungkin serius menghantui kita dalam 8000 tahun. Kode hidup lebih lama daripada yang diharapkan ...…
deceze

15
@menerima ISO8601 sudah memiliki ketentuan untuk tahun 5 digit, tetapi akan menarik untuk melihat implementasi DateTime mana yang saat ini mengizinkannya.
Zac Faragher

4
@ ZacFaragher, saya yakin kita akan punya banyak waktu untuk mengimplementasikannya nanti, tidak perlu terburu-buru, kan ...?
ilkkachu

51
@menerima Mengapa Anda mencairkan saya - sudahkah Anda menemukan cara untuk menyembuhkan kanker? Tidak, ini tahun 9999 dan Anda tahu COBOL.
user3067860

6
Anda mungkin ingin memperbaiki kesalahan ketik Anda. Kata millennia , jamak dari milenium , wajib dieja dengan double-N untuk mencocokkan double-N dalam tahunan dari annus Latin untuk tahun. Ketika Anda salah mengeja dengan hanya satu-N, itu sekarang tidak cocok dengan tunggal-N anal dari anus Latin dengan makna yang sama seperti kata pinjaman ke dalam olahraga Inggris. Singkatnya, Anda selalu perlu mengejanya dengan cara yang berarti Anda berbicara tentang ribuan tahun, bukan ribuan lubang-butt. :)
tchrist

57

Apakah ada alasannya?

Iya. Perangkat lunak tersebut akan menggunakan ISO 8601 .

ISO 8601 memiliki sejumlah keunggulan dibandingkan format tanggal lainnya:

  • Ini standar dengan dokumen spesifikasi :)
  • Tidak ambigu. mm / dd / yyyy dan dd / mm / yyyy dapat membingungkan kecuali melewati hari ke-13.
  • Ini secara leksikografis mengurutkan ke dalam urutan waktu naik, sehingga tidak ada logika penyortiran tanggal khusus yang diperlukan. Ini sangat berguna dalam nama file, di mana penyortiran nomor leksikografis sering membingungkan (misalnya 1_file, 10_file, 2_file).
  • Ini mandat tahun 4 digit dan nol bulan dan tahun empuk. Ini menghindari masalah tahun 2000 dan ambiguitas lainnya.

Adapun mengapa ISO 8601 ada di tempat pertama, itu karena orang-orang menemukan format tanggal ambigu dan membingungkan ketika bertukar data antar negara / sistem, dan mereka membutuhkan sesuatu yang tidak ambigu.

Untuk alasannya lihat pengantar spesifikasi .

Meskipun Rekomendasi dan Standar ISO dalam bidang ini telah tersedia sejak 1971, berbagai bentuk representasi numerik tanggal dan waktu telah umum digunakan di berbagai negara. Di mana representasi tersebut dipertukarkan melintasi batas-batas negara, salah tafsir mengenai pentingnya angka dapat terjadi, yang mengakibatkan kebingungan dan kesalahan atau kerugian konsekuensial lainnya. Tujuan dari Standar Internasional ini adalah untuk menghilangkan risiko salah tafsir dan untuk menghindari kebingungan dan konsekuensinya.

...

Standar Internasional ini mempertahankan ekspresi yang paling umum digunakan untuk tanggal dan waktu hari itu dan representasi mereka dari Standar Internasional sebelumnya dan memberikan representasi unik untuk beberapa ekspresi baru yang digunakan dalam praktik. Penerapannya dalam pertukaran informasi, terutama antara sistem pemrosesan data dan peralatan terkait akan menghilangkan kesalahan yang timbul dari salah tafsir dan biaya yang ditimbulkannya. Promosi Standar Internasional ini tidak hanya akan memfasilitasi pertukaran lintas batas internasional, tetapi juga akan meningkatkan portabilitas perangkat lunak, dan akan memudahkan masalah komunikasi dalam suatu organisasi, serta antar organisasi.

Standar mendefinisikan variasi "dasar" sebagai meminimalkan penggunaan pembatas. Jadi, YYYYMMDDadalah alternatif dasar untuk format yang diperluas YYYY-MM-DD.


4
Saya tidak tahu bahwa ISO 8601 juga memungkinkan YYYYMMDD selain YYYY-MM-DD.
keuleJ

iso.org/iso-8601-date-and-time-format.html tampaknya menunjukkan bahwa "Format yang diperluas" dari YYYY-MM-DD adalah satu-satunya format untuk 8601?
Oskar Austegard

3
@keuleJ Meminimalkan penggunaan pembatas seperti YYYYMMDD daripada YYYY-MM-DD disebut variasi format "dasar" dalam standar ISO 8601.
Basil Bourque

Dua manfaat lebih dari ISO 8601: (a) Mudah diurai oleh mesin tanpa karakter SPACE dan tanpa teks yang dilokalkan, dan (b) Mudah diintegrasikan oleh manusia lintas budaya dengan tahun yang akan datang lebih dulu mudah dikenali (jika kontemporer), dan tanpa mengasumsikan bahasa Inggris.
Basil Bourque

55

Itu karena semua cara lain untuk melakukannya adalah ambigu.

01/02/2003 apa artinya itu? Januari kedua 2003? Atau di Eropa: 1 Februari 2003? Semakin buruk jika Anda menggunakan dua digit untuk tahun ini, seperti 01/02/03.

Itulah mengapa Anda menggunakan YYYYMMDD, itu adalah konvensi yang memungkinkan kami untuk berkomunikasi dengan jelas tentang tanggal, 20030201 karena tanggalnya selalu jelas. (dan membuatnya lebih mudah untuk disortir)

(Sekarang jangan menyimpannya sebagai bilangan bulat 20 juta 30 ribu dua ratus dan 1. tolong ok? Cantik tolong?)


14
"20030201 sebagai kencan selalu jelas" : Itu sama sekali tidak terjadi. Sama ambigu dengan "01/02/2003" kecuali Anda tahu bahwa YYYYMMDD (atau apakah YYYYDDMM atau DDMMYYYYY? ...) adalah format yang digunakan. Anda SELALU perlu mengetahui format tanggal; tidak ada "konvensi" yang membuat segala sesuatu menjadi tidak ambigu.
skomisa

6
@skomisa itu sangat salah. ISO 8601 menetapkan format tanggal standar internasional khusus untuk alasan yang Anda nyatakan. Tidak ada format lain yang merupakan format tanggal yang valid dan belum ada sejak 19880605
K. Alan Bates

11
@ K.AlanBates Kencan Anda ambigu kecuali kami menganggap bahwa itu harus diuraikan sesuai dengan ISO 8601.
Goyo

16
20030201 adalah 20 Maret 201AD, kan?
David Richerby

10
@ Martijn, tetapi khusus bahasa. Di Turki, ini adalah Şubat daripada Februari (Sebelum Anda berpikir kode Anda berfungsi, selalu periksa Turki ).
NH.

19

Biarkan t1 dan t2 menjadi bilangan bulat berbeda yang mewakili dua kali ditulis dalam format YYYYMMDD. Kemudian t1 <t2 menyiratkan bahwa t2 terjadi setelah t1.

Anda kehilangan pemesanan ini dengan pemformatan pertama DD dan MM.

ISO adalah, IMO, satu-satunya format yang masuk akal.


1
Kecuali Anda tidak akan pernah menyimpan ini sebagai bilangan bulat, setidaknya saya belum pernah melihatnya atau mempertimbangkannya.
pipa

5
@pipe: Percayalah, beberapa orang akan melakukannya. Kami mempertahankan sistem lama yang menyimpan YYYYMMDD sebagai bilangan bulat. Desain mungkin berasal dari beberapa sistem database lama tanpa tipe tanggal yang jelas dan disimpan untuk kompatibilitas. Itu tidak cantik. Jangan lakukan itu.
Heinzi

19
@pipe, sudah menjadi pengalaman saya dalam industri perangkat lunak bahwa setiap kali orang yang berakal ingin mengatakan "Tapi Anda tidak akan pernah melakukan X" selalu ada setidaknya satu contoh balasan
Joseph Rogers

5
@pipe Dalam pergudangan data, tidak jarang menggunakan integer yyyymmdd sebagai kunci utama / pengganti untuk tabel tanggal.
soapygopher

4
@pipe, well, nomor urut zona DNS adalah bilangan bulat 32-bit, yang harus ditingkatkan ketika zona berubah. Walaupun bisa jadi hanya angka biasa, idiom yang umum adalah menggunakan angka seperti 2018092601 ... Lalu ada beberapa definisi aneh angka ajaib yang dijelaskan dalam feature_test_macros(7), seperti memiliki _POSIX_C_SOURCE > 200809Lberarti bahwa fitur dari POSIX.1-2008 didukung ...
ilkkachu

12

Satu hal yang tidak disebutkan adalah bahwa, dalam input interaktif, format ini memungkinkan untuk mengontrol input.

Sistem tidak dapat mengetahui apakah suatu bulan memiliki 28, 29, 30 atau 31 hari tanpa mengetahui tahun dan bulan tertentu. Ketika input interaktif memberi mandat bahwa tahun dan bulan datang lebih dulu, ia dapat memeriksa apakah hari (yang dimasukkan terakhir) dalam kisaran yang diizinkan.

Memang, pertanyaannya sebagian besar tentang format tanggal, tetapi dapat diperdebatkan bahwa format tanggal mengikuti format yang disajikan kepada pengguna.


7

YYYYMMDD memesan tanggal dengan cara yang sama seperti Anda memesan nomor: porsi paling signifikan terlebih dahulu. MMDDYYYY akan seperti menulis "seratus dua puluh tiga" sebagai "dua puluh dan seratus tiga".

Dalam budaya kita, kita memiliki pemahaman alami tentang MMDDYYYY karena, sebagai manusia, kita memiliki kesadaran akan waktu, dan tahun-tahun berjalan lambat. Kita umumnya tahu tahun berapa itu. Melihat tahun jarang penting, jadi kami mendorongnya ke belakang. Bulan berubah cukup cepat untuk mempertahankan kepentingannya. Budaya lain menangani hal ini secara berbeda. Banyak dunia lebih suka DDMMYYYY.


62
Anda mungkin ingin menguraikan kembali "budaya kita" karena dalam budaya saya itu adalah DDMMYYYY jadi bukan budaya "kita" hanya milik Anda
slebetman

66
Peta lengkap dari semua negara yang menggunakan format tanggal MMDDYYYY img-9gag-fun.9cache.com/photo/a2mXmGd_700b.jpg
Peregrine

9
Tampak seperti argumen aneh: "Berbulan-bulan berubah cukup cepat untuk mempertahankan kepentingannya" -> Mengapa tidak mendahulukan hari sejak perubahan itu lebih cepat?
Wim Deblauwe

7
@ JoelCoehoorn, mudah untuk membuatnya eksplisit ("Dalam budaya AS kami"). "our" / "we" sering digunakan untuk berarti "komunitas stackexchange" di sini.
AnoE

14
Persis. Stackoverflow bersifat internasional . Bahwa Anda berbasis di AS tidak mengatakan, menyiratkan, atau bahkan membuatnya lebih mungkin bahwa orang lain juga. Anda tidak dapat membuat asumsi tentang lokalitas pembaca Anda di sini, mereka ada di seluruh dunia. Dan sebagian besar pembaca Anda bukan Anda, bukan OP, tetapi orang lain yang menemukan jawaban Anda di Google. Komentar ini ditulis di benua yang berbeda dari yang Anda tinggali. Dan sementara kita memiliki kebiasaan kita sendiri - ehm - yang menarik , kita tentu saja tidak menggunakan MM / DD / YYYY di sini ...
cmaster

6

Penyortiran telah disebutkan tetapi sejauh ini alasan paling berguna untuk dilakukan adalah membandingkannya sebagai "string", dan ya stempel waktu 26 karakter dipesan dengan cara yang sama.

Saya menyadari perbandingan semacam itu sangat penting untuk menyortir, tetapi umumnya berguna untuk elemen 2 elemen.

Saya telah mengerjakan proyek di mana ini tidak diadopsi, dan ya, programmer mencoba (dengan hasil beragam) untuk membandingkan tanggal sebagai string.

Pemformatan cantik adalah untuk sisi klien atau pengaturan huruf.


5

Format ini membuat urutan alfabet string identik dengan urutan kronologis tanggal. Ini berguna karena banyak alat menyediakan urutan abjad file misalnya dengan nama, tetapi tidak ada cara untuk menguraikan tanggal yang diformat secara sewenang-wenang dari nama file dan mengurutkannya.


4

Ini tentang pembatasan. Bayangkan YEAR, MONTH, dan DAY sebagai parameter, dalam format YYYYMMDD setiap parameter lebih ketat daripada yang sebelumnya.

Jadi, jika Anda ingin mencari sesuatu yang terjadi pada tahun 1970 Anda dapat melakukannya dengan mencari sebuah string yang dimulai "1970*", tetapi jika Anda mengingat bulan yang Anda dapat menambahkan bulan seperti "197005*". Dengan cara ini setiap "parameter" tanggal memberi Anda informasi yang lebih spesifik.

Ini satu-satunya cara untuk beralih dari info yang kurang spesifik ( "1970*") ke info yang lebih spesifik ( "19700523").


3
Sebenarnya bukan argumen yang bagus - sama biasa untuk mencari hal-hal yang terjadi pada bulan-bulan tertentu daripada tahun-tahun tertentu.
Cubic

1
Jika 1970*dan 197005*mewakili sintaks wildcard "glob", maka Anda dapat mencari sekelompok tanggal MMDDYYYY dengan mencari glob *1970atau 05*1970. Jawaban Anda mungkin secara implisit mengasumsikan beberapa kendala tambahan yang tidak Anda sebutkan secara eksplisit, dan dapat ditingkatkan dengan menjelaskan asumsi Anda.
Quuxplusone

3
Ini adalah semacam efek samping atau cara lain untuk menggambarkan urutan kunci yang disebutkan oleh jawaban lain. Tetapi penjelasan ini berantakan kecuali Anda membatasi untuk mencari pada awalan. (Lebih mudah diindeks, tetapi tidak berarti diperlukan).
Peter Cordes

Ini juga berarti Anda dapat memilih urutan tanggal dengan regexp yang relatif sederhana ...
Harper

1

Mengapa, dalam pemrograman, format tanggal default adalah YYYYMMDD ...

Ini adalah format yang dapat dibaca manusia untuk input dan output, tidak harus disimpan seperti itu.

Lebih dari sepertiga dari semua bahasa pemrograman dikembangkan di negara dengan bahasa Inggris sebagai bahasa utama dan sebagian besar yang modern mematuhi Standar beberapa deskripsi - Standar internasional untuk tanggal adalah ISO 8601 .

Info lebih lanjut: (TMI?)

Ketika waktu berubah, biasanya maju, kenaikan hari pertama, lalu bulan, tahun terakhir - mungkin lebih mudah untuk memahami jika kita memiliki tanggal desimal (dan waktu desimal ) - seiring berjalannya waktu angka semakin besar. Lebih mudah bagi manusia untuk melihat jumlahnya dan membandingkannya dengan kencan lain secara sekilas.

Komputer tidak peduli struktur apa yang ingin Anda gunakan dan di sebagian besar (tetapi tidak semua ) logika biner komputer digunakan - basis e sebenarnya memiliki ekonomi radix terendah tetapi bukan yang paling efisien atau termudah untuk urutan lengkap .

Format input dan output aktual untuk tanggal berbeda-beda di setiap negara dan diatur oleh lokalisasi , sementara YYYYMMDD mungkin tampak paling masuk akal dan menjadi apa yang Anda terbiasa dengannya tidak universal hari ini, juga tidak seperti itu di masa lalu untuk waktu yang lama, namun bahkan hari ini angka Romawi yang umum digunakan untuk tanggal .

Mengetahui tahun depan memberi tahu Anda jumlah hari dalam setahun, variasi durasi terbesar yang bisa dijalani setahun. Ini memberitahu Anda dimuka jumlah hari di setiap bulan untuk mengikuti (untuk pengecekan kesalahan saat masuk), mengizinkan input hari pertama mungkin harus mendukung Anda jika tahun berikutnya tidak setuju dengan input Anda - mungkin membuat input yang dapat diakses lebih sulit . Ini juga memiliki arti penting berkaitan dengan format kalender . Lihat juga kalender geek , dengan stardate desimalnya.

Sejauh menyangkut komputer itu kemungkinan akan menggunakan waktu UNIX Epoch , jumlah detik yang telah berlalu sejak 00:00:00 Waktu Universal Terkoordinasi (UTC), Kamis, 1 Januari 1970, di mana setiap hari diperlakukan seolah-olah mengandung tepatnya 86400 detik. Lihat juga hari Julian . Format YYYYMMDD lebih disukai oleh manusia egosentris, IAU menganggap satu tahun sebagai tahun Julian dari 365,25 hari (31,5576 juta detik) kecuali dinyatakan sebaliknya.


1
Sebenarnya hampir setiap manusia dan perangkat lunak yang pernah saya temui lebih memilih format lain.
Goyo

1
Senang bertemu denganmu! Saya Dave, dan saya lebih suka YYYYMMDD
Reversed Engineer

0

Penggunaan lain yang saya lihat untuk representasi ini adalah Anda dapat menyimpan tanggal sebagai bilangan bulat (yaitu dalam database), hanya menggunakan 4 byte per tanggal. Dengan menggunakan YYYYMMDD berarti perbandingan integer (seringkali instruksi mesin tunggal) memiliki hasil yang sama dengan perbandingan pada tanggal yang diwakili. Dan itu mencetak cukup mudah dibaca manusia. Dan semua ini tidak memerlukan kode atau dukungan khusus sama sekali, di lingkungan pemrograman mainstream.

Jika hal-hal itu sebagian besar dari apa yang perlu Anda lakukan dengan tanggal, dan Anda perlu melakukan banyak hal, maka format ini memiliki banyak daya tarik.

Sebagai perbandingan, tanggal dalam format umum seperti DD / MM / YYYY mengambil 10 byte sebagai string karakter ASCII. String YYYYMMDD menguranginya menjadi 8 dan mendapatkan keuntungan "membandingkan representasi memiliki hasil yang sama dengan membandingkan tanggal", tetapi bahkan perbandingan berbasis string lebih bersifat karakter per karakter daripada perbandingan integer tunggal.


2
Ini sepele untuk mengemas tanggal menjadi tiga byte. Kisaran 0000 ~ 9999 membutuhkan 14 bit, 01 ~ 12 membutuhkan 4 bit, dan 01 ~ 31 membutuhkan 5 bit, dengan jumlah 23 bit. Dengan menggunakan juga bit yang tersisa dalam kuantitas tiga byte, Anda dapat mewakili tanggal selama periode 32.768 tahun mempertahankan resolusi satu hari. Ini dapat digunakan, misalnya, untuk memungkinkan mewakili tanggal dalam rentang tahun 8191 SM hingga 24576 AD. Dengan mengemas bit sebagai, katakanlah, yyyyyyyyyyyyyyymmmmddddd, representasi desimal tetap sebanding secara langsung (meskipun tidak langsung dapat dibaca manusia, tetapi siapa yang peduli dalam penyimpanan fisik basis data?).
CVn

0

Alasan yang sama Bulan terbuat dari keju hijau: bukan. Dalam kebanyakan kasus, format default adalah semacam string terlokalisasi. Terkadang format ISO digunakan tetapi biasanya dengan tanda hubung untuk keterbacaan yang lebih baik. YYYYMMDD(atau %Y%m%ddalam strftimeistilah) jarang yang default. Agar adil saya yakin saya telah melihatnya tetapi saya tidak bisa memikirkan contoh saat ini.

Tanggal unix (utilitas inti GNU)

date

Keluaran:

Wed Sep 26 22:20:57 CEST 2018

Python

import time
print(time.ctime())

keluaran:

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

Keluaran:

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

Keluaran:

Wed Sep 26 22:51:22 2018

Javascript

current_date = new Date ( );
current_date;

Keluaran:

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

SQLite

SELECT date('now');

Keluaran:

2018-09-26

LibreOffice Calc

masukkan deskripsi gambar di sini

Gnumerik

masukkan deskripsi gambar di sini

OnlyOffice

masukkan deskripsi gambar di sini

Python + numpy

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

Keluaran:

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

Python + panda

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

Keluaran:

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

Rekayasa Perangkat Lunak

masukkan deskripsi gambar di sini

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

alternative.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

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

10
untuk menambah argumen Anda, berapa banyak dari mereka yang diformat seperti itu karena pengaturan pengguna di komputer tempat Anda menjalankan skrip?
Topher Brink

Yang pertama bukan benar-benar "bash", ini adalah program tanggal (dan hasilnya di Do 27. Sep 22:27:09 CEST 2018sini.)
Paŭlo Ebermann

@ PaŭloEbermann Anda benar, saya harap sekarang lebih baik. Seperti yang saya katakan banyak format ini dilokalkan sehingga format aktual yang Anda lihat akan tergantung pada opsi pelokalan Anda.
Goyo

3
Meskipun inti dari Jawaban ini berlaku untuk aplikasi berorientasi pengguna akhir, tidak demikian halnya untuk pertukaran data antar sistem, serialisasi data, protokol pesan / data, pencatatan, penelusuran, pelacak, dan sebagainya. Standar ISO 8601 dengan cepat menjadi norma untuk penggunaan semacam itu yang ditujukan untuk admin dan pemrogram sistem. Ditto untuk skenario internasional atau agnostik lokal.
Basil Bourque

@BasilBourque Terima kasih, saya menambahkan sampel acak dari log yang saya temukan di sistem saya sendiri. Saya tidak punya contoh tipe lain yang berguna. Tapi saya tidak berpikir bahwa tren menuju default ke ISO 8601 di domain tertentu membuat varian dasarnya "default dalam pemrograman" di hadapan sejumlah besar perangkat lunak yang default ke format lain.
Goyo

-1

Manfaat tambahan yang tidak disebutkan sejauh ini adalah bahwa kuantisasi yang diinginkan (menetapkan nilai tepat sebagai milik rentang nilai umum yang sama) adalah operasi tunggal yang relatif mudah dan cepat.

Misalkan Anda sedang menulis laporan yang merangkum acara hari ini, seperti jumlah dan jumlah penjualan. Tanggal dan waktu penjualan disimpan sebagai YYYYMMDDHHMISS, Anda hanya perlu menyimpan 8 karakter paling kiri (jika berupa string) atau integer divide (yaitu lantai) sebanyak 1.000.000 untuk mengurangi waktu Anda hingga hari penjualan.

Demikian pula, jika Anda menginginkan penjualan bulan itu, Anda hanya menyimpan 6 digit paling kiri, atau membagi dengan 100.000.000

Tentu, Anda bisa berargumen bahwa manipulasi string apa pun dimungkinkan, suatu masa untuk penjualan "12-25-2018 12:34" dapat dikurangi dan dimanipulasi beberapa kali untuk mendapatkan bulan dan tahun. Dalam bentuk angka 122520181234 dapat dibagi dan diubah, dan dikalikan, dan dibagi lagi, dan akhirnya juga menghasilkan satu bulan dan satu tahun ... ... tetapi kode itu akan sangat sulit untuk ditulis, dibaca, dipelihara, dan dimengerti ..

Dan bahkan pengoptimasi basis data yang canggih mungkin tidak dapat menggunakan indeks pada kolom untuk klausa di mana jika formulir tanggal adalah MM / DD / YYYY tetapi potong dan potong kembali bersama-sama. Sebagai perbandingan, menyimpan representasi YYYYMMDD dan menginginkan Desember 2018 mengarah ke tempat klausa sejenisnya dateasstring LIKE '201812%'atau dateasint BETWEEN 20181200 and 20181299- sesuatu yang indeks dapat dengan mudah digunakan untuk

Jadi, jika tidak ada tipe data khusus untuk tanggal dan representasi string / numerik adalah satu-satunya pilihan, menggunakan dan menyimpan waktu dalam beberapa representasi interval-waktu-terpanjang-di-kiri-ke-pendek-interval-di-the- right memiliki beberapa manfaat untuk kemudahan pemahaman, manipulasi, penyimpanan, pengambilan dan pemeliharaan kode

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.