Best practices: Daylight saving time and Timezone

SpirallingTime

שיטות עבודה מומלצות עם DateTime אזורי זמן ושעון הקיץ

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

הנה לכם הוכחה קצרצרה שטיפול לא נכון בנתוני DateTime ב.NET יכול לגרום לכשלים קריטיים דומים. נתבונן בקוד הבא:

static void Main(string[] args)
{
    var start  = new DateTime(2011, 10, 2, 0, 0, 0);
    var finish = new DateTime(2011, 10, 2, 2, 0, 0);

    Console.WriteLine((finish - start).TotalHours); // output: 2 INCORRECT!!
    Console.ReadKey();
}

בשביל ההמחשה נניח שאני צריך לכתוב תוכנה שמחשבת אורך שיחה של לקוחות ספק תקשורת סלולרית. כשלקוח מחייג, אני רושם במשתנה start אז זמן תחילת השיחה (02/10/2011 00:00:00), וכשהוא מנתק, מציב בfinish את זמן סיום השיחה (02/10/2011 02:00:00). בסיום השיחה התוכנה מחשבת את אורך השיחה ומחזירה את מספר השעות שארכה השיחה לצורך חיוב הלקוח. במקרה שלפנינו, בהתחשב בזמני תחילת וסיום השיחה, התוכנה פולטת שהלקוח שלי דיבר במשך שעתיים.

ברוב ימות השנה זו אפילו תהיה התוצאה הנכונה. הבעיה היא, שבדיוק באותו היום ישראל עברה משעון קיץ לשעון חורף. כלומר, בזמן שהלקוח שלי היה באמצע השיחה, החזירו את השעון הישראלי מהשעה 01:59:59 לשעה 01:00:00. נמצא, שכשהתוכנה שלי רשמה את שעת סיום השיחה ב2 לפנות בוקר לפי שעון חורף (שהרגע הוחל) זה בעצם היה ב3 לפנ"ב לפי שעון הקיץ. והלקוח שלי שהתחיל את השיחה לפי שעון הקיץ בעצם דיבר 3 שעות ולא 2!

למרות שמעבר השעון מתרחש בשעות הלילה הפחות פעילות, בעולם שכולו OnLine הסיכוי הוא שגם בשעות האלו התוכנה\אתר\שירות שלכם יהיו פעילים. ואם הם כתובים בצורה לא נכונה - הם יבצעו חישובים ופעולות שגויות! עוד...

קטגוריות: .NET | מדריכים

באג בUpdatePanel וIE בURLים עבריים

כידוע, ASP.NET WebForms משמר את הערכים של הפקדים בדף בין הpostbackים ע"י שימוש בform אחד המכיל, בדרך כלל, את כל שאר התגיות שבדף. בנוסף, בWebForms מקובל שכל דף עושה post לעצמו. כלומר, בדף default.aspx הערך של האטריבוט action של הform יהיה בדרך כלל גם כן default.aspx:

<form method="post" action="default.aspx" id="form1">
    ...
</form>

בנוסף, ASP.NET מבצע אופטימיזציה לURL המופיע בaction שיהיה יחסי לURL הנוכחי. כך למשל בדף הזמין בכתובת /blog/default.aspx הערך של action יהיה default.aspx בלבד.

למה זה חשוב? כנראה, בגלל ש .NET 4.0 היא הגרסה הראשונה של הframework שבה WebForms תומך בRouting, ומאפשר URLים ידידותיים, לא חשבו על תסריט של כתובת URL ידידותיות ובעברית, או לפחות לא בדקו את המימוש בצורה מספיקה.

לגבי מה הדברים אמורים?

נניח שהגדרנו Route כדלהלן:

RouteTable.Routes.MapPageRoute("bug", "באג/{unicode}", "~/default.aspx");

עכשיו, אם נגלוש לכתובת "/באג/בדיקה", נגיע לדף default.aspx כשהערך של הפרמטר unicode הוא "בדיקה". כמו"כ, בדף שיוגש לנו הערך של הaction בform יהיה, כצפוי, "בדיקה".

<form method="post" action="בדיקה" id="form1">
   ...
</form>

כעת אם הדף default.aspx יעשה PostBack לעצמו, השאילתא תתבצע בהצלחה, ותיראה כך:

POST /%D7%91%D7%90%D7%92/%D7%91%D7%93%D7%99%D7%A7%D7%94 HTTP/1.1

עד כאן הכל טוב ויפה. הבעיה מתחילה כשמנסים לבצע CallBack מאותו הדף. עוד...

קטגוריות: .NET 4.0 | IIS | .NET
תגיות: , , , , , ,