קבלת תאריך לא UTC מאנגולר 2 לצד שרת
-
בפרוייקט שבו אני נמצא כעת, יש אפשרות לסינון לפי תאריך במסך מסויים
המתכנת של החלק הזה (@רפאל , שהוא בחור מוכשר מאד), שעושה גם את החלק של האנגולר 2 וגם את הצד שרת של החלק הזה (כתוב בC# Core), הראה לי שברגע שהבקשה מגיע מהאנגולר, התאריך בטווח תאריכים הוא שעת UTC, מה שמשפיע על הסינון מול הDB
אם למקד את הבעיה, כששולחים בקשה עם JSON.stringify, זה מגיע בUTC
נסו לדוגמא לכתוב בקונסולJSON.stringify(new Date())ותראו שהשעה חוזרת UTC (בלי offset)
בDB השעה נשמרת כמו שהיא (TimeZone ישראל), ולא UTC, (בעיקר בגלל צורת תיכנון מסויימת - הנושא הזה כנראה לא הולך להשתנות בזמן הקרוב - אלא בזמן מאוחר יותר), ולכן הסינון מביא נתונים פחות 3 שעות (כי כעת פער הTimeZone בארץ מול Utc עומד על 3 שעות) - הבעייה מתחדדת מ12 בלילה גם במקרים שהסינון הוא רק לפי תאריך ולא מכיל גם שעות- האם נתקלתם בזה?
- רעיונות להעביר את הזמן עם TimeZone ישראלי, אבל שיהיה גנרי ללא התערבות בקוד כל הזמן
- יש לכם רעיון אחר בנידון?
ממש תודה רבה
-
-
-
@clickone אתה חייב לשלוח את זה ב-TZ ישראלי? למה לא תוכל לשנות את הקוד שבונה את השאילתה בצורה שהיא תתייחס לאיזורי זמן? כלומר, ה-Z בסוף מחרוזת הדייט, הרי מסמל שזה זמן UTC. אתה לא יכול להוסיף קוד בשרת שימיר את זה ל-DATETIME באיזור הזמן הישראלי ואז לתשאל את ה-DB? (אולי אפשר לעשות את זה ב-SQL גם כן. לא ציינת איזה DB. אני מניח שזה MSSQL?)
-
-
@yossiz - קודם כל תודה
אנחנו מחפשים שיהיה גנרי כדי לא לאחוז ראש כל הזמן שצריך להעביר את השעה לזמן ישראליכמובן שאם אפשר לעשות דריסה זה יכול להיות מצויין.
כמובן שאם אין שום ברירה אז אין ברירה ונצטרך בצד שרת לעשות הכל
(כי שם גם יש קלאס חיצוני שמנתח את הבקשה ומייצר ממנה SQL וכו' - שזה אומר גם שם להתערב פנימית)ומצד שני לדרוס פונקצייה כ"כ בסיסית בלי לחשוב מעכשיו על כלל ההשלכות של זה...
-
@clickone אוקיי הבנתי. לענ"ד אין שום השלכה לדריסה זו חוץ מהשלכה חיובית אחת שתקבל את המחרוזת הרצויה
. אם אתה רוצה להיות עוד יותר שמרני, אפשר לדרוס את הפונקציה עבור המופע ולא על הפרוטוטייפ (כמובן זה פתרון פחות ג'נרי)
רק שאבין, אם תדרוס בצורה שהיא תחזיר מחרוזת בפורמט ISO עם offset זה יעזור? או שתצטרך להתערב יותר ולהחזיר מחרוזת בלי איזור זמן כלל או עם זמן UTC לא נכון?
כי אם תוכל להחזיר פרומט ISO עם אופסט קשה לי להאמין שיהיה שום השלכה שלילית. אם תצטרך להתערב יותר, אולי יש מקום להיות יותר שמרני. -
@clickone
לא לגמרי קראתי לעומק מה יוסי כתב, וכנראה שהוא ענה או פתר את העניין,
רק רוצה לכתוב שגם לי היו כמה סיטואציות כאלה ובכולן מה שעשיתי היה העברה של הdatetime הזה מהקליינט - במקום ב-datetime string - הוצאתי את ה-UNIX timestamp ממנו ואת זה שלחתי לשרת.
(וכמובן בשרת מתרגם את ה-UNIX בחזרה ל-date string או יותר נכון date object)זה לדעתי הפיתרון הנכון וזה סידר אצלנו כמה בעיות.
ב-JS מקבלים UNIX timestamp פשוט על ידי
()getTime
ככהconsole.log(new Date(Date.now()).getTime())עריכה הסתכלתי במה שכתבתי והבנתי שיכול להיות שהצורך שאתה מדבר הוא שונה ממה שאני מכיר.
הפתרון שלי הוא למקרה שבו אני לא רוצה לתת ליוזר לסנן לפי הזמן שלו. כלומר גם אם הוא בארה"ב- הזמנים שהוא יראה בדשבורד (נגיד) יהיו לפי ישראל.
והפילטרים שאני נותן לו יחולו על פי ישראל.כנראה הצורך שלך שונה אז סתם בלבלתי את המוח
יוסי תקן אותי אם יש לך סבלנות..
-
@chv אני לא מבין את דבריך.
כדי שהבעיה תהיה ברורה אקדים:
להקדמה נאמר שכאשר בני אדם מדברים אחד עם השני על נקודה מסויימת בזמן, בד"כ הם לא מציינים את הזמן האבסולוטי אלא את הזמן היחסי בצורה של מספר שעות אחרי תחילת היום באזור הזמן שלהם. אבל באפליקציה שצריכה להתנהל מול כמה אזורי זמן זה בעייתי, כי לא כל המשתתפים מסכימים על נקודת הציון שכל הזמנים הם יחסים לה. לכן צריך דרך לציין זמן אבסולוטי במקום זמן יחסי.
לשם פתרון בעיה זו צריך שיהיה מוסכמה איך מציינים זמן אבסולוטי. ולשם כך הומצאו שתי דרכים לפתרון: א) מציינים גם את הזמן וגם את האופסט מ-GMT שהיא אזור זמן מוסכם שמשתמש כנקודת ציון קבועה לצורך חישוב אופסט. ב) מסכימים להשתמש בזמן אחיד ואבסולוטי במקום זמן יחסי. זה מה שנקרא UTC.
הבעיה של @clickone הוא שבתוך ה-DB שלו יש זמן יחסי. (בלי לציין ביחס למה. שזו צורה בעייתית לשמירת זמן.). כרגע זה לא מפריע לו כל כך כי כל הנוגעים בדבר נמצאים בארצנו הקדושה לכן אין בעיה להתשמש בזמן יחסי בעת שכל הנוגעים בדבר מסכימים ביחס למה.הבעיה הוא שהדפדפן משתמש בזמן אבסולוטי, מכיון שזה הדבר ההגיוני שצריך לעשות.
ובעת המרה למחרוזת הוא מקבל את זה כזמן אבסולוטי בצורת UTC.
זה לעצמו לא בעיה כי זמן אבסולוטי הוא יותר מדוייק ויש בו יותר מידע מזמן יחסי. זה יחסי + נקודת ציון שנדע ביחס למה. אם כן אמור להיות בכלל מאתים מנה.
אבל משום מה, הקוד בצד השרת שלו לא עושה את התרגום הזה בעת התשאול ל-DB. כנראה בגלל שהזמן ב-DB לא כולל שום נקודת ציון והוא יחסי לגמרי, השרת לא יודע למה להמיר ולכן הוא לא עושה שום המרה כלל.לכן @clickone רוצה לקבל זמן יחסי מהדפדפן. עד כאן הקדמה.
עכשיו שהבעיה ברורה. אני לא מצליח להבין את הפתרון שלך.מה שאני לא מצליח להבין בדבריך הוא מה ההבדל בין שימוש ב-UTC בפורמט ISO לבין unix timestamp. הרי ה-unix timestamp גם מציין זמן ב-UTC. ואם כן מה הועלת? שתי הפורמטים הם פשוט שתי דרכים להציג אותם נתונים בדיוק!
-
@yossiz צודק, מה שכתבתי פשוט לא קשור למה ש @clickone שאל.
ועכשיו שאני קורא את הכותרת זה אפילו הפוך לחלוטין ממה שכתבתי.
אבל אני פשוט יסביר מה היה אצלי הצורך כי שאלת גם על עצם מה שכתבתי,מה שקרה זה (היה כמה סיטואציות, ניקח אחת מהן, ש=)אני מחזיר מהבקאנד מערך של זמנים (=datetime objects שמומרים ל-JSON סטרינגיפי)
ואני מצפה מהיוזר לשלוח לי בחזרה זמנים (כלומר נגיד - אני מרנדר לו את הזמנים האלו בתוך כפתורים, הוא בוחר אני יודע מה הוא בחר ושולח בחזרה לבקאנד את מה שהוא בחר)
הבעיה כאן היתה - שהבקאנד (שולף זמנים מתוך ה-DB, פוסטגרס. ששומר את הזמנים עם TZ של ישראל) משום מה ממיר את הזמנים ושולח אותם בלי TZ. (למה הוא עושה את זה? לא ברור לי, אבל לא היה לי עניין לנסות לשנות)
כלומר בפרונטאנד - ה-JS לא יכול לדעת איזה TZ האובייקט date שהוא יצור מהסטרינג שייך. הוא פשוט עושה new Date וזה כמובן נהיה datetime object של UTC.מה שקורה זה שכשאני שולח את הזמן הזה (UTC) בחזרה לבאקנד בצורה הרגילה ג'ייסונית (ISO) - הבקאנד בשלב הפרסור של זה לאובייקט היה מפרסר את זה כישראל - ומכניס/משווה עם ה-DB בצורה שגויה
(יש כאן הרבה שאלות שהייתי צריך לשאול, ולבדוק. עיקר השאלה על פייתון שהוא הבק)לכן מה שעשיתי זה לשלוח מהפרונט את הזמנים - כ-UNIX (שזה UTC)
ולפרסר אותם בפייתון לאובייקט של זמן, ואת הזמנים האלו הוא פירסר לזמן מתאים ונכון!! והשווה בצורה הנכונה מול ה-DB, והכניס בצורה נכונה ל-DB.מה שיוצא זה שצריך לבדוק:
- אולי המנגנון שפייתון מפרסר timestamp ל-datetime object הוא שונה מהמנגנון שהוא מפרסר סטרינג של datetime בפורמט ISO ל-datetime object
- אולי יש כאן משהו שבכלל קשור ל-DB אבל לא נראה כך (לא יכול להיות שזה הבעיה)
- אולי היה לי איזה משהו טכני אחר שלא שמתי אליו לב. לא עולה לי בראש
מה שבטוח שזה לא פיתרון או קשור כנראה לבעיה המקורית של האשכול, אז סליחה @clickone ..
