ב-1 בנובמבר 2026, כמה פרובינציות וטריטוריות בקנדה – מניטובה, אלברטה, קולומביה הבריטית וחלקים מהטריטוריות הצפון-מערביות – יעברו לשעון קיץ קבוע או יישארו בהפרשי השעות של שעון הקיץ ביחס ל-UTC, במקום להזיז את השעון שעה אחת אחורה.
במסד הנתונים של אזורי הזמן של IANA (tzdata 2026e), השינויים האלה מעדכנים את אזורי הזמן והכינויים הבאים:
| אזור | הפרש קבוע משעון UTC לאורך כל השנה (החל מ-1 בנובמבר 2026) | אזורי הזמן המושפעים של IANA |
|---|---|---|
| מניטובה | UTC-5 (במקום לחזור ל-UTC-6) | אמריקה – ויניפג (America/Winnipeg), קנדה – מרכז (Canada/Central), אמריקה – רייני ריבר (America/Rainy_River) |
| אלברטה | UTC-6 (במקום לחזור ל-UTC-7) | אמריקה – אדמונטון (America/Edmonton), קנדה – אזור ההר (Canada/Mountain) |
| קולומביה הבריטית | UTC-7 (במקום לחזור ל-UTC-8) | אמריקה – ונקובר (America/Vancouver), קנדה – האוקיינוס השקט (Canada/Pacific) |
| הטריטוריות הצפון-מערביות | UTC-6 (במקום לחזור ל-UTC-7) | אמריקה – אינוביק (America/Inuvik) |
במסמך הזה מוסבר איך השינויים האלה באזורי הזמן משפיעים על Looker, ואיך אפשר למנוע הפרש של שעה החל מ-1 בנובמבר 2026.
איך השינויים באזור הזמן משפיעים על Looker
השינויים באזורי הזמן בקנדה ב-2026 משפיעים על התכונות של Looker באופן שונה, בהתאם למקום שבו מתבצעת הערכת אזור הזמן – במסד הנתונים או ב-Looker:
- שאילתות SQL, מסננים ומאפיינים מותאמים אישית: כש-Looker יוצר SQL ל-Explore, לטבלת Look או ללוח בקרה, Looker מעביר למסד הנתונים את מזהה אזור הזמן של IANA שהוגדר. מסדי נתונים מנוהלים בענן, כמו BigQuery, מקבלים את העדכון של
tzdata 2026eבאופן אוטומטי. אם אתם מנהלים את מסד הנתונים בעצמכם, ודאו שטבלאות אזורי הזמן של מסד הנתונים כוללות את גרסהtzdata 2026eאו גרסה מאוחרת יותר. - זמני הפעלה של מסירה מתוזמנת: Looker משתמש בנתוני אזור הזמן של המתזמן המצורף (Ruby) כדי להעריך את לוחות הזמנים של cron למסירת תוכן. במופעים של Looker שלא תוקנו, זמני ההפעלה של לוחות הזמנים באזורי הזמן המושפעים בקנדה יהיו שגויים בשעה אחת החל מ-1 בנובמבר 2026. אפשר לפתור את הבעיה הזו באמצעות גרסאות build מתוקנות של Looker וגם באמצעות פתרון עקיף של אזור הזמן של זמן האספקה.
- חישובים בטבלה בממשק המשתמש: כשמציגים חקירה או מרכז בקרה בממשק המשתמש של Looker, המערכת מעריכה חישובים בטבלה שמשתמשים ב-
now()בדפדפן באמצעות נתוני אזור הזמן של הדפדפן (JavaScript) שמצורפים. במכונות שלא עודכנו, החישובים האלה יהיו שגויים בשעה אחת החל מ-1 בנובמבר 2026. גרסאות Looker עם תיקון פותרות את הבעיה הזו. - חישובים בטבלה שמוערכים בשרת: כש-Looker מעריך חישובים בטבלה שמשתמשים ב-
now()בשרת – כולל בהורדות של קובצי CSV ו-XLSX, נתונים בתוך מסירות מתוזמנות, שאילתות API והתראות – Looker פועל ב-JVM, שמסד הנתונים של אזור הזמן של ה-JDK המצורף שלו הוא עדייןtzdb 2026b. התיקון לא מעדכן את ה-JDK המצורף, ולכן החישובים שלnow()שמוערכים בשרת לאזורי הזמן המושפעים בקנדה עדיין לא מדויקים בשעה אחת החל מ-1 בנובמבר 2026, גם בגרסאות Looker שתוקנו.
בטבלה הבאה מפורטות התכונות של Looker שמתוקנות באמצעות גרסה עם תיקון, ואלה שאפשר לעקוף באמצעות הגדרה של אזור זמן חלופי:
| תכונה | הבעיה תוקנה באמצעות גרסה מתוקנת? | הבעיה נפתרה באמצעות פתרון עקיף של אזור זמן חלופי? |
|---|---|---|
| מועדי ההפעלה של מסירה מתוזמנת | כן (מעדכן את נתוני אזור הזמן של Ruby בתזמון) | כן (עדכון אזור הזמן של המסירה המתוזמנת, שמשפיע רק על מועד השליחה של המסירה) |
חישוב בטבלה now() בממשק המשתמש (ב-Explores ובלוחות הבקרה) |
כן (מעדכן את נתוני אזור הזמן של JavaScript בדפדפן) | לא מומלץ (צריך לשנות את אזורי הזמן ברמת השאילתה, מה שגורם להזזה של נתוני החורף ההיסטוריים בשעה אחת בתוצאות ה-SQL) |
החישוב בטבלה now() מתבצע בשרת (הורדות של קובצי CSV ו-XLSX, נתונים בתוך מסירות מתוזמנות, API והתראות) |
לא ב-Looker (Google Cloud core) ובמכונות שמתארחות ב-Looker (ב-JVM נעשה שימוש ב-JDK tzdb 2026b בחבילה) |
לא מומלץ (צריך לשנות את אזורי הזמן ברמת השאילתה, מה שגורם להזזה של נתוני החורף ההיסטוריים בשעה אחת בתוצאות ה-SQL) |
כדי למנוע סטייה של שעה במסירות מתוזמנות ובחישובים בטבלה בממשק המשתמש, שדרגו לגרסה מתוקנת של Looker. אם אתם לא יכולים להחיל את התיקון לפני 1 בנובמבר 2026, אתם צריכים להגדיר אזור זמן חלופי לשעת יעד בלוחות הזמנים שלכם.
שדרוג לגרסה של Looker עם תיקון
Looker מספקת גרסאות תיקון שמעדכנות את נתוני אזור הזמן של המתזמן (Ruby) והדפדפן (JavaScript) ל-tzdata 2026e בכל הגרסאות הנתמכות של Looker, חוץ מ-Looker 26.0. גרסאות ה-build המתוקנות זמינות ל-Looker בגרסאות 25.18, 26.0, 26.6, 26.12, 26.16, 26.18, 26.20 ו-26.22, וגם לגרסאות מאוחרות יותר. ב-Looker (Google Cloud core) ובמכונות שמתארחות ב-Looker, גרסאות ה-build המתוקנות לא מעדכנות את מסד הנתונים של אזור הזמן של ה-JDK המצורף (tzdb 2026b) ב-JVM, כך שהחישובים בטבלה now() שמוערכים על ידי השרת נשארים בהפרש של שעה אחת.
Looker לא תפרוס את התיקון הזה באופן אוטומטי בכל המופעים לפני 1 בנובמבר 2026. אתם יכולים לבקש או להוריד גרסה מתוקנת של Looker, בהתאם לגרסה שבה אתם משתמשים:
- מכונות של Looker (Google Cloud core) ומכונות שמתארחות ב-Looker: כדי לבקש שדרוג לגרסה עם תיקון למכונה שלכם, פנו אל Cloud Customer Care.
- אירוח בצד הלקוח: כדי לקבל את קובצי ה-JAR המתוקנים לגרסת Looker הנתמכת, הורידו את הגרסה המעודכנת מדף ההורדה של Looker או פנו אל Cloud Customer Care.
- חישובים בטבלה שמוערכים בשרת: חישובים בטבלה שמוערכים בשרת משתמשים בנתוני אזור הזמן של סביבת זמן הריצה של Java, ולא ב-JDK מקובץ. מעדכנים את נתוני אזור הזמן של סביבת זמן הריצה של Java, למשל באמצעות הכלי
tzupdaterשל Oracle, כדי שאזורי הזמן המושפעים בקנדה, כמוAmerica/Winnipeg, יוערכו בצורה נכונה. - חותמות זמן של פעילות המערכת: אם אזור הזמן של המערכת בשרת מוגדר לאזור זמן בקנדה שמושפע מהשינוי, כמו
America/Winnipeg, חותמות הזמן של פעילות המערכת גם יהיו שגויות בשעה אחת החל מ-1 בנובמבר 2026.
- חישובים בטבלה שמוערכים בשרת: חישובים בטבלה שמוערכים בשרת משתמשים בנתוני אזור הזמן של סביבת זמן הריצה של Java, ולא ב-JDK מקובץ. מעדכנים את נתוני אזור הזמן של סביבת זמן הריצה של Java, למשל באמצעות הכלי
הגדרת אזור זמן חלופי
אם לא תשדרגו לגרסה מתוקנת לפני 1 בנובמבר 2026, או אם המכונה שלכם מריצה את Looker 26.0, תוכלו להגדיר אזור זמן חלופי שתואם להפרש הזמן של האזור שלכם מ-UTC:
- מניטובה (
America/Winnipeg,Canada/Central,America/Rainy_River— UTC-5): בוחרים אזור זמן שנשאר ב-UTC-5 לאורך כל השנה בלי לעבור לשעון קיץ, כמו אמריקה – אטיקוקן (America/Atikokan), אמריקה – קנקון (America/Cancun), אמריקה – פנמה (America/Panama), אמריקה – בוגוטה (America/Bogota), אמריקה – לימה (America/Lima) או אמריקה – ג'מייקה (America/Jamaica). - אלברטה (
America/Edmonton,Canada/Mountain) והטריטוריות הצפון-מערביות (America/Inuvik— UTC-6): בוחרים אזור זמן שנשאר ב-UTC-6 לאורך כל השנה בלי לעבור לשעון קיץ, כמו America - Regina (America/Regina), Canada - Saskatchewan (Canada/Saskatchewan), America - Guatemala (America/Guatemala), America - Costa_Rica (America/Costa_Rica) או America - Belize (America/Belize). - קולומביה הבריטית (
America/Vancouver,Canada/Pacific— UTC-7): בוחרים אזור זמן שנשאר ב-UTC-7 לאורך כל השנה בלי שעון קיץ, כמו America - Phoenix (America/Phoenix), America - Dawson_Creek (America/Dawson_Creek), America - Fort_Nelson (America/Fort_Nelson), America - Creston (America/Creston), America - Whitehorse (America/Whitehorse) או America - Dawson (America/Dawson).
עדכון הגדרות אזור הזמן ב-Looker
כדי למנוע מצב שבו מסירות מתוזמנות יופעלו בהפרש של שעה, צריך לעדכן את אזור הזמן של המסירה בלוחות הזמנים המושפעים לאזור זמן חלופי. שינוי אזור הזמן של לוח הזמנים לא משפיע על הנתונים, כי הוא קובע רק מתי התוכן יישלח ולא את הנתונים מבוססי הזמן שהשאילתה מחזירה (ראו שימוש בהגדרות של אזור הזמן):
- אזור הזמן של האפליקציה: מעדכנים את ההגדרה Application Time Zone בדף General Settings בחלונית Admin כדי להגדיר את אזור הזמן שמוגדר כברירת מחדל ללוחות זמנים חדשים. בכל לוח זמנים קיים נשמר אזור הזמן שלו, ולכן עדיין צריך לעדכן כל לוח זמנים קיים בנפרד.
- העברות תוכן מתוזמנות: פותחים כל לוח בקרה, Look או Explore שמושפעים מהשינוי, ומעדכנים את הגדרת אזור הזמן להעברה. הוראות מפורטות מופיעות במאמרים תזמון ושליחה של מרכזי בקרה ושליחת תצוגות וניתוחים.
אם אתם עדיין רוצים לעדכן את הגדרות אזור הזמן ברמת השאילתה כדי לעקוף את הבעיה של now() בחישובים בטבלה, ומוכנים לקבל את השינוי של שעה אחת בתוצאות ה-SQL ההיסטוריות של החורף, אתם יכולים לשנות את ההגדרות הבאות במקומות שבהם מוגדר אזור זמן קנדי שמושפע מהבעיה:
- אזורי זמן של חשבונות משתמשים: אם האפשרות User Specific Time Zones מופעלת, מעדכנים את אזורי הזמן של המשתמשים בדף Users בחלונית Admin. משתמשים פרטיים יכולים גם לעדכן את ההגדרה אזור זמן בדף חשבון.
- אזור הזמן של השאילתות בחיבור למסד הנתונים: אם האפשרות אזורי זמן ספציפיים למשתמש מושבתת, מעדכנים את ההגדרה אזור הזמן של השאילתות בדף Connections בחלונית Admin.