فرمت برچسب زمانی

فهرست مطالب:

• خلاصه
  • مسئله
  • تصمیم
  • وضعیت
• جزئیات
  • مفروضات
  • قیود
  • مواضع
  • استدلال
  • پیامدها
• مرتبط
  • تصمیمات مرتبط
  • الزامات مرتبط
  • مصنوعات مرتبط
  • اصول مرتبط
• توضیحات

خلاصه

مسئله

می‌خواهیم بتوانیم با استفاده از برچسب‌های زمانی و یک فرمت یکدست برچسب زمانی که در همهٔ سیستم‌های ما و سیستم‌های شخص ثالث خوب کار کند، پیگیری کنیم که چیزها چه زمانی رخ می‌دهند.

با سیستم‌هایی تعامل داریم که فرمت‌های برچسب زمانی متفاوتی دارند:

• پیام‌های JSON فرمت بومی برچسب زمانی ندارند، بنابراین باید انتخاب کنیم چگونه یک برچسب زمانی را به رشته تبدیل کنیم و رشته را به برچسب زمانی تبدیل کنیم، یعنی چگونه سریال‌سازی/ناسریال‌سازی کنیم.

• برخی برنامه‌ها به جای زمان UTC برای استفاده از زمان محلی تنظیم شده‌اند. این می‌تواند برای پروژه‌هایی که باید با زمان محلی سازگار شوند، مانند پروژه‌هایی که رویدادهای مبتنی بر زمان محلی را فعال می‌کنند، راحت باشد.

• برخی سیستم‌ها نیازها و قابلیت‌های متفاوتی برای دقت زمان دارند، مانند استفاده از وضوح زمانی ثانیه در برابر میلی‌ثانیه در برابر نانوثانیه. برای مثال، فرمان date در سیستم‌عامل Linux به‌طور پیش‌فرض از دقت ثانیه استفاده می‌کند، در حالی که بورس سهام Nasdaq به‌طور پیش‌فرض دقت نانوثانیه می‌خواهد.

تصمیم

فرمت استاندارد برچسب زمانی ISO 8601 با دقت نانوثانیه را برمی‌گزینیم، به‌طور مشخص "YYYY-MM-DDTHH:MM:SS.NNNNNNNNNZ".

این فرمت سال، ماه، روز، ساعت، دقیقه، ثانیه، نانوثانیه و منطقهٔ زمانی زولو، که UTC و GMT نیز نامیده می‌شود، را نشان می‌دهد.

وضعیت

تصمیم گرفته شد.

جزئیات

مفروضات

باید این رشته‌های متنی برچسب زمانی را مدیریت کنیم، برای تبدیل از برچسب زمانی به رشته (که سریال‌سازی نیز نامیده می‌شود) و تبدیل از رشته به برچسب زمانی (که ناسریال‌سازی نیز نامیده می‌شود).

فرمتی می‌خواهیم که به‌طور کلی استفاده از آن آسان، تبدیل آن آسان و خواندن آن برای انسان آسان باشد.

سازگاری با طیف وسیعی از سیستم‌های بیرونی را می‌خواهیم که نمی‌توانیم آن‌ها را کنترل کنیم، مانند سیستم‌های تحلیلی، سیستم‌های پایگاه داده، سیستم‌های مالی.

قیود

برخی سیستم‌ها محدودیت‌های دقت زمان دارند. برای مثال، فرمان date در سیستم‌عامل macOS می‌تواند دقت زمان را بر حسب ثانیه چاپ کند، اما بر حسب نانوثانیه نه.

مواضع

طیفی از گزینه‌ها را بررسی کردیم:

• Unix epoch، یعنی یک عدد فزاینده.

• فرمت متنی فشرده "YYYYMMDDTHHMMSSNNNNNNNNN".

• استفاده از منطقهٔ زمانی محلی در برابر منطقهٔ زمانی UTC.

استدلال

برای استفادهٔ معمول، به راحتی خواندن/نوشتن برای انسان بیش از سرعت/اندازهٔ خام ارزش می‌دهیم.

برای استفادهٔ معمول، فرمتی می‌خواهیم که در سیستم‌های ماشینی خوب کار کند و همچنین به‌صورت دستی نیز خوب کار کند، مانند نوشتن داده‌های نمونه، خواندن خروجی JSON، grep کردن یک فایل لاگ و غیره.

برای استفادهٔ غیرمعمول، مانند محاسبات با کارایی بالا، انتظار داریم بخواهیم هر فرمت متنی را که انتخاب کنیم با تبدیل متن به فرمت سریع‌تر، مانند نوع شیء تاریخ داخلی یک زبان برنامه‌نویسی، بهینه کنیم. بنابراین فرمت متنی برای HPC چندان اهمیت ندارد.

پیامدها

سیستم‌های متنی و سیستم‌های زمانی گوناگون ما بر این فرمت همگرا خواهند شد.

مرتبط

تصمیمات مرتبط

ممکن است راهی سریع/آسان برای پیگیری تفاوت‌های زمانی، که مدت نیز نامیده می‌شوند، هم بخواهیم. این‌ها با برچسب‌های زمانی Unix epoch آسان‌اند.

الزامات مرتبط

ممکن است بخواهیم تصمیم خود را تنظیم کنیم، مثلاً اگر نیازمندی مرتبطی برای نوع خاصی از مهر پیام لاگ، مانند Splunk، Sumo، ELK و غیره، داشته باشیم.

مصنوعات مرتبط

قالب‌بند و تجزیه‌گر زبان‌ها:

• date-fns: Modern JavaScript date utility library
• Crono: date and time library for Rust

نمونه‌های Rosetta Code:

• System time
• Data format
• Show the epoch

نمونه‌های SixArm:

• now_string

اصول مرتبط

به‌آسانی برگشت‌پذیر. می‌توانیم نسبتاً آسان به فرمت دیگری، مانند Unix epoch، تغییر دهیم.

از بهینه‌سازی زودهنگام بپرهیزید. برای استفادهٔ معمول مشتی نویسهٔ اضافی، مانند فرمتی که از خط تیره و دونقطه استفاده می‌کند، چندان مهم نیست.

توضیحات

توضیحات را اینجا اضافه کنید.