איזה פורמט לחותמות זמן ב-JSON
שורה תחתונה: למספרי epoch ולמחרוזות ISO יש כל אחד פשרות, אבל ערבוב שלהם הוא מה שבאמת שובר דברים. השתמשו ב-ISO 8601 עם offset, אחסנו UTC, והציגו באזור הזמן של המשתמש.
שורה תחתונה: השתמשו ב-ISO 8601 עם offset מפורש על החוט, אחסנו UTC עם Z בסוף, והמירו רק בזמן התצוגה; אם תבחרו מספרי epoch במקום, קבעו גלובלית שניות מול מילישניות ושימו את היחידה בשם השדה.
למה 2026-10-30 14:30:00 לא מספיק
המחרוזת הזו לא נושאת אזור זמן. 14:30 בשנגחאי ו-14:30 בלונדון רחוקים שמונה שעות, ואין דרך לדעת מה הכוונה. new Date('2026-10-30 14:30:00') נפרס באזור הזמן המקומי של ה-runtime, כך שהשרת והדפדפן מסיקים שני רגעים שונים מ-payload אחד — סוג הבאג שלעולם לא משחזר.
2026-10-30 חשוף הוא בכלל לא רגע. מתאים לימי הולדת ותקופות חיוב, שגוי לזמן יצירה.
שני פורמטים שאפשר לעבוד איתם
מחרוזות ISO 8601
{
"createdAt": "2026-10-30T14:30:00+08:00",
"updatedAt": "2026-10-30T06:30:00Z"
}
קריא, ניתן למיון כשהפורמט עקבי, דיוק מילישניות אם צריך, ומתאר את עצמו.
מספרי epoch
{ "createdAt": 1793519400 }
קומפקטי וחד-משמעי, אבל לא קריא, ושניות מול מילישניות היא סכנה קבועה. אם בוחרים epoch, תקננו את היחידה ושימו אותה בשם השדה: createdAtMs בטוח הרבה יותר מ-createdAt.
מוסכמות שכדאי לקבוע מוקדם
| פריט | מוסכמה |
|---|---|
| פורמט על החוט | ISO 8601 עם Z או +08:00 |
| אזור אחסון | UTC, כך ש-DST לא נכנס לתמונה |
| דיוק | מילישניות מספיק |
| שמות שדות | createdAt, updatedAt, expiresAt |
| תאריכים טהורים | שדה date נפרד, למשל birthday: "1990-01-01" |
| משכים | מספר שלם ועוד יחידה, למשל timeoutMs: 3000 |
הצגה
new Intl.DateTimeFormat('en-GB', {
dateStyle: 'medium',
timeStyle: 'short',
timeZone: 'Europe/London',
}).format(new Date('2026-10-30T06:30:00Z'));
ציינו timeZone במפורש כשהתצוגה לא צריכה ללכת לפי המכשיר. הסתמכות על ברירת המחדל של הדפדפן נכונה לזמנים שמוצגים למשתמש ושגויה לדוחות.
שלושה באגים חוזרים
תאריכים חשופים נפרסים כחצות UTC. לפי מפרט ECMAScript, מחרוזות של תאריך בלבד הן UTC בעוד מחרוזות של תאריך-שעה הן מקומיות. חוסר העקביות הזה הוא מקור אמין לבאגים של יום אחד לכאן או לכאן.
אזור מסד הנתונים לא מסכים עם הסריאליזר. ל-datetime של MySQL אין אזור זמן; כתבו מקומי, קראו כ-UTC, והכל נזז ב-offset.
שעון קיץ. אחסון זמנים מקומיים עתידיים יוצר רגעים שלא קיימים או מתרחשים פעמיים. ל-UTC אין פערים כאלה.
שאלות ותשובות
איך לבחור בין ISO 8601 למספרי epoch?
השתמשו ב-ISO 8601 כשבני אדם קוראים את ה-payload, כשרוצים סדר מיון לקסיקלי, או כשהערך חייב לשאת את אזור הזמן שלו; המחיר הוא בערך תריסר בייטים נוספים וספריית פירוס. השתמשו במספרי epoch כשקומפקטיות וטיפול פשוט בין-שפות חשובים יותר, אבל קבעו גלובלית שניות מול מילישניות ואמרו איזו יחידה השדה מחזיק.
האם תאריך חשוף וחותמת זמן צריכים לחלוק את אותו שדה?
לא. 2026-10-30 חשוף הוא יום לוח שנה בלי שעה ובלי אזור זמן, בעוד ששדה חותמת זמן אמור לשאת רגע מדויק. שמרו ימי הולדת ותקופות חיוב בשדה date נפרד, והשתמשו בשדה ISO 8601 עם סיומת At לזמני יצירה או עדכון.