DanLevy.net

חותמת הזמן שלך משקרת

מה כרטיס רכבת לימד אותי על אחסון זמן במסדי נתונים

הזמנתי רכבת מניו יורק לשיקגו, ואז הבנתי למה טיפוסי timestamp ב-Postgres כל כך מבלבלים. הכרטיס הראה:

שלוש דרכים שונות לדבר על זמן, כולן על אותו כרטיס. וכל אחת מהן צריכה להישמר אחרת בבסיס נתונים.

השאלה שאף אחד לא שואל קודם

גם TIMESTAMP וגם TIMESTAMPTZ ב-Postgres תופסים בדיוק 8 בתים עם אותה דיוק של מיקרו-שניות. אז למה יש בכלל שני טיפוסים?

כי “מה השעה?” תלוי לגמרי במה אתה מנסה להגיד למישהו.

כשאני עולה על הרכבת הזו בניו יורק, אני צריך לדעת שהיא יוצאת ב-8:00 AM שעון מזרח. זה המספר על השעון בתחנה שאני צריך להתאים אליו. כשהחברה שלי אוספת אותי בשיקגו, היא צריכה לדעת שאני מגיע ב-7:30 PM שעון מרכזי – זה המספר על השעון שלה. ואם אני מנסה להבין אם יהיה לי זמן לקרוא את הספר שלי, אני צריך לדעת שזה מסע של 11 וחצי שעות.

אותה רכבת. אותו מסע. שלוש ייצוגים שונים לחלוטין של זמן.

מה TIMESTAMPTZ באמת עושה

הנה הטריק עם TIMESTAMPTZ – וזה לא מה שרוב האנשים חושבים. הוא לא שומר את אזור הזמן. השם מטעה.

מה שהוא עושה זה להמיר כל זמן שאתה נותן לו ל-UTC לפני האחסון, ואז להמיר אותו בחזרה לאזור הזמן של הסשן שלך כשאתה קורא אותו. החלק “TZ” לא קשור לאחסון, אלא לתמיכה בהמרה.

נניח שאתה מאחסן את היציאה של הרכבת הזו. מישהו בטוקיו שולח שאילתה למסד הנתונים שלך ורואה את היציאה ב-JST. מישהו בלונדון רואה אותה ב-GMT. כולם מסתכלים על אותו רגע מוחלט, רק מבוטא באזור הזמן המוגדר שלהם. זה מושלם לתיעוד אירועים: “מתי התשלום הזה עובד?” או “מתי בקשת ה-API הזו התרחשה?”

אבל מה לגבי כרטיס הרכבת הזה? אתה לא רוצה שזמן היציאה ישתנה רק בגלל שמישהו שואל אותו מאזור זמן אחר. הרכבת יוצאת ב-8:00 AM שעון מזרח, נקודה. זה לא רגע מוחלט בזמן – זו הבטחה לגבי מה שהשעון בגרנד סנטרל יראה.

אחסון מה שאתה באמת מתכוון אליו

בשביל מסע הרכבת הזה, אתה צריך לאחסן דברים שונים למטרות שונות:

עכשיו האפליקציה שלך יכולה לעשות מה שכרטיס הרכבת עושה: להציג “יוצא 8:00 AM EST” על ידי המרת הרגע המוחלט לאזור הזמן של המוצא, להציג “מגיע 7:30 PM CST” על ידי המרה לאזור הזמן של היעד, ולהציג “משך: 11h 30m” ישירות מהמרווח.

האדם שמזמין את הכרטיס מטוקיו רואה את אותם זמנים מקומיים בכל תחנה. זה מה שהוא צריך לדעת.

למה אפליקציית מעקב הטיסות שלך טעתה

שמת לב איך כמה אפליקציות מעקב טיסות מציגות את אזור הזמן שלך במהלך הטיסה? כאילו אתה מעל האוקיינוס האטלנטי וכתוב “זמן נוכחי: 4:32 PM GMT.” למי אכפת? אתה לא בגריניץ’, אתה בגובה 38,000 רגל איפשהו מעל האוקיינוס.

מה שאתה באמת רוצה לראות:

אף אחד מאלה אינו המרת אזור זמן. השניים הראשונים הם מרווחים—משכים, לא רגעים. האחרון הוא המרת אזור זמן, אבל למקום ספציפי, לא ל”אזור הזמן הנוכחי שלך.”

רואה? שתי חישובי מרווח (NOW() - actual_departure ו-estimated_arrival - NOW()), המרת אזור זמן אחת למקום ספציפי (AT TIME ZONE destination_timezone). אזור הזמן הנוכחי שלך לא נכנס לתמונה.

כשזמן שעון קיר הוא מה שאתה באמת צריך

למלונות לא אכפת מרגעים מוחלטים בזמן. אכפת להם מקריאות שעון במיקום שלהם.

“צ’ק-אין אחרי 15:00” לא אומר “צ’ק-אין 15 שעות אחרי חצות UTC.” זה אומר “כשהשעון בלובי שלנו מראה 15:00, אתה יכול להיכנס.” אם השרתים שלך בווירג’יניה אבל המלון בפריז, אתה עדיין רוצה שהכלל הזה יופעל בשעה 15:00 שעון פריז.

הטיפוס TIME (ללא תאריך או אזור זמן) מייצג בדיוק את זה: “קריאה על שעון.” צרף אותו לשדה טקסט של אזור זמן (“Europe/Paris”), ותוכל לאכוף מדיניות שעון קיר בלי קשר למקום שבו השרתים שלך חיים. אבל תרצה גם עמודות TIMESTAMPTZ עבור מתי אורחים ספציפיים נכנסים ויוצאים בפועל—אלה רגעים מוחלטים שהבאקנד שלך צריך לעקוב אחריהם.

בעיית היומן

יש לי תזכורת חוזרת שנקבעה ל-9:00: “סקור סדרי עדיפויות יומיים.” אני רוצה שהתזכורת הזו תופיע בשעה 9:00 לפי המקום שבו אני נמצא. אם אני נוסע, היא עדיין צריכה להופיע בשעה 9:00 שעון מקומי.

אבל יש לי גם אירוע יומן: “סטנדאפ צוות בשעה 10:00 EST.” חבר הצוות שלי בברלין צריך לראות “16:00 CET” לאותו אירוע. אותה פגישה, זמני תצוגה שונים, כי זו רגע מוחלט שכולנו מצטרפים אליו.

שני סוגים שונים של אירועים, שתי אסטרטגיות אחסון שונות. הפגישה מקבלת TIMESTAMPTZ. התזכורת מקבלת TIME בתוספת הגדרת אזור הזמן הנוכחי שלי. הימנע מלנסות לדחוס את שניהם לאותו שדה.

הדברים שנשברים בייצור

אפילו עם הטיפוסים הנכונים, דיוק יכול להפתיע אותך. Postgres מאחסן מיקרו-שניות: 10:00:00.123456. אובייקט Date של JavaScript משתמש במילי-שניות: 10:00:00.123.

אז השאילתה הזו עלולה להחזיר ללא שורות באופן מסתורי:

SELECT * FROM orders WHERE created_at = '2026-01-15 10:00:00.123';

למסד הנתונים יש 10:00:00.123456 והקוד שלך מעביר 10:00:00.123. תלוי איך הדרייבר שלך מטפל בזה, ייתכן שהם לא יתאימו.

אל תשתמש בשוויון מדויק עבור חותמות זמן. השתמש בשאילתות טווח, או יותר טוב—אל תחפש רשומות לפי חותמת הזמן של היצירה שלהן בכלל. השתמש באילוץ ייחודי מתאים או במפתח אידמפוטנטיות.

כללים מעשיים

ברירת מחדל ל-TIMESTAMPTZ. כשיש ספק, השתמש ב-TIMESTAMPTZ. הוא מטפל בפריסות רב-אזוריות, שעון קיץ, ושינויי אזור זמן עתידיים באופן אוטומטי. גודל האחסון זהה ל-TIMESTAMP, כך שאין קנס.

אחסן הקשר בנפרד. אם אתה צריך להציג “יוצא 8:00 AM EST” לצד הרגע בפועל, אחסן גם את ה-TIMESTAMPTZ וגם את origin_timezone כעמודות נפרדות. אל תנסה לקודד הכל לשדה אחד.

חשוב על מרווחים. הרבה דרישות הקשורות לזמן הן למעשה על משך, לא על רגעים. “כמה זמן זה תלוי ועומד?” “מתי זה יפוג?” השתמש בפעולות INTERVAL, לא בהמרות אזור זמן.

הפעל הכל ב-UTC. השרתים שלך צריכים להיות מוגדרים ל-UTC. הפעלות מסד הנתונים שלך צריכות להיות ב-UTC כברירת מחדל. המיר לאזורי זמן מקומיים רק בעת הצגה למשתמשים, ורק כאשר אתה יודע איזה אזור זמן רלוונטי.

דרוש מידע על אזור זמן מלקוחות. אם לקוח שולח 2026-01-15T10:00:00 ללא היסט, דחה אותו. דרוש פורמט ISO-8601 עם Z או היסט מפורש כמו -05:00. אל תנחש.

אכיפת ברירות מחדל טובות

אם TIMESTAMPTZ הוא ברירת המחדל שלך (וכך צריך להיות), שקול לאכוף זאת ברמת מסד הנתונים. טריגר שדוחה עמודות TIMESTAMP WITHOUT TIME ZONE נשמע קיצוני, אבל לתפוס “שכחתי להוסיף TZ” בזמן יצירת הסכימה עדיף מאשר לנפות באגים שישה חודשים לאחר מכן כשמישהו מוסיף טבלה חדשה ושוכח.

מה לימדה אותי כרטיס הרכבת ההוא

זמן במסדי נתונים אינו קשה כי חותמות זמן מסובכות. זה קשה כי בדרך כלל אנו מאחסנים מספר דאגות בשדה אחד, או לא חושבים על מה שאנחנו באמת מנסים להראות למשתמשים.

כרטיס הרכבת ההוא צדק: שעת יציאה באזור זמן המוצא, שעת הגעה באזור זמן היעד, ומשך הזמן כדבר נפרד לחלוטין. שלושה חלקי מידע שונים, כל אחד משמעותי בדרכו שלו.

מסד הנתונים שלך יכול לעשות את אותו הדבר. אחסן את הרגעים המוחלטים כ-TIMESTAMPTZ. אחסן את הקשר התצוגה (אזורי זמן, מיקומים) כעמודות נפרדות. השתמש בסוגי INTERVAL למשכים. תן ל-Postgres לבצע את ההמרות כשאתה צריך אותן, אבל היה מפורש לגבי איזה אזור זמן רלוונטי לאיזו מטרה.

רוב הזמן, זה אומר TIMESTAMPTZ ו-UTC בכל מקום, עם המרות אזור זמן רק בזמן תצוגה. אבל כשאתה צריך זמני שעון קיר או לוחות זמנים חוזרים, סוגי TIMESTAMP או TIME קיימים בדיוק מהסיבה הזו.

המפתח הוא לדעת איזו שאלה אתה מנסה לענות: “מתי זה קרה?” לעומת “באיזו שעה אני צריך להיות שם?” לעומת “כמה זמן זה ייקח?” כולן שאלות שונות על זמן, ולעתים קרובות הן דורשות אסטרטגיות אחסון שונות.

חשוב מה המשתמשים שלך צריכים לראות. ואז אחסן את הנתונים שמאפשרים לך להציג להם בדיוק את זה.

משאבים

Loading comments...