6 ms·

The 1 Hour per Year Bug, but only in Pacific time

76 points by tomeraberbach 2y ago

mulmen 2y ago
I’m having a hard time following how such naive time handling became part of a Google product. Pick an epoch for timekeeping. Timezones are a display issue.
- crote 2y ago
  No, it isn't. That approach works fine for things like logging where are your timestamps are in the past, but the moment you have to deal with future timestamps it leads to some truly horrible issues when some political leader decides to change the definition of the timezone. Suddenly all your future epoch-based datetimes are representing the wrong wall clock time...
  - londonlawyer 2y ago
    [dead]
  - mulmen 2y ago
    Timekeeping is always epoch based. When the definition changes you update the display code. There’s no way to write code today that accounts for future changes in local time.
    - hansvm 2y ago
      That's the same kind of mentality that kept Google Calendar from being able to schedule a monthly meeting on the last day of the month. If you scheduled it on the 31st, the tool would happily accept that 5 months each year wouldn't have your monthly meeting. Suppose I have an 8am alarm to wake up in the morning. I want that to happen once per day in my current local timezone. If I change locations, the epoch I'm being alarmed at should change. If I travel quickly enough to experience multiple 8ams, I only want one of them (the first one). If laws change to give me multiple 8ams in a single locale, it's ambiguous which one I want. How your alarm app handles that varies, but you should do _something_ (flag the situation in the app, pick one (if one of them is about the same epoch as the previous alarm, maybe pick that one), ...). For calendars you have probably a different set of choices. If all participants are in the same time zone, you probably want the meeting to move as regulations change the definition of 8am. If they're in different time zones which all practice daylight savings and the meeting doesn't conflict with any of the 1-2am haunted hours then the meeting should probably move with daylight savings, reference the local time as it was defined when the meeting was created, and not move as some dictator redefines a time zone (becoming a cross between a display issue and actually considering local time). If you don't know anything as a calendar app about the participants, there will be edge cases where you make bad decisions, so you either accept that or flag the ambiguity when appropriate. And so on. If we can convince everyone to switch to some kind of atomic time without leap seconds I'd be tickled pink. That's not the world we live in though.
      - mulmen 2y ago
        That’s the difference between the 31st and the last day of the month. It’s a UX issue, not a timekeeping issue.
    - toast0 2y ago
      Storing epochs for future times that are specified in local time usually isn't enough considering that local time zones change. If you only deal in times and time zones where time zone changes are announced far enough in advance that zone changes can be processed before any events they effect are in the system, it doesn't matter. But if people schedule things years out in countries with reasonable notice, or weeks out in countries where there's a lack of notice, there's a good chance of doing things wrong. To accomidate these future dates, you should store the localtime and you should also store the offset and/or an epoch determined at time of storage. When rules change, you should evaluate future events and for events where the calculated epoch changes, storing and using the new epoch is a sensible default --- you should ideally show the user a summary of changes, so they can adjust if they have things that were entered in local time for convenience but are actually scheduled in a different zone.
  - Dylan16807 2y ago
    But the context of the article was logging and purely a display issue.
- saagarjha 2y ago
  Googlers are not all timekeeping experts, nor are they all capable of summoning that knowledge at all times when writing code.
  - mulmen 2y ago
    It just seems like something Google would have solved in a general sense. It’s a hard problem, asking everyone to get it right is unrealistic, clearly.
Moru 2y ago
Can we talk about all the problems with dates formated as "today", "tomorrow" or "2 hours ago" when trying to figure out how far apport two log-events happened? I at least want an OPTION to set that I want all dates down to the second exactly when they happened... And in a standard format with Y-M-D H:m:s that can sort naturally. The most significant part first, the least significant last.
- noja 2y ago
  Yeah at least I want a mouseover to see the real timestamp, and the column to be sortable.
- stephen_g 2y ago
  The absolute worst are ones like “last month”, “last week” or “earlier this week” - almost absolutely useless! Especially for logs of things that happened at work, I extremely frequently want to know the day and date something happened, but that style obscures that sometimes to the point where you can’t even tell which week it was!
  - Moru 2y ago
    And if you save something and need to look it up a year later it's even less useful. Last week computed from save date? File save date changed because zip-file didn't save the date? Well, now it's worse than useless, now it's missleading.
  - bigiain 2y ago
    I consider those as "management oriented time deltas". Usually specifically requested by Project Managers because they're so imprecise that they can avoid being held responsible for anything...
  - Aardwolf 2y ago
    I also hate "1 year ago" when it was actually 23 months ago
    - tonyhart7 2y ago
et-al 2y ago
> Normally I would have dismissed that as a coincidence, but daylight saving time also ended at 11:00pm (PT) on November 7! Huh? Unless I'm mistaken, Daylight Saving ended at 2am local time on Nov 7, 2021. Was the bug that Day Saving is internally set based on Eastern Time (i.e. 2am ET / 11pm PT)?
- Laughsalot 2y ago
  This is my understanding as well. and and Wikipedia backs me up on it [https://en.wikipedia.org/wiki/Pacific_Time_Zone#Daylight_time https://en.wikipedia.org/wiki/Pacific_Time_Zone#Daylight_tim...]. Some of the software I've written _explicitly_ disables scheduling mobile notifications during the transition periods so I was also very confused by that. Your ET speculation makes sense to me. I'll bet that whatever server/containers being used for the backend were running in the Eastern Timezone.
  - waffletower 2y ago
    Normalizing to a zoned date (vs. an epoch representation) during a transition period is problematic. During the transition periods (unique to each daylight time zone) the temporal distance between timezones changes (increases or decreases by 1) temporarily.
- cortesoft 2y ago
  Sounds like the library that is converting their internal eastern time representation of the datetime to local time is determining the daylight savings time before converting. Or it is just assuming a standard offset, not taking into account the 6 hours a year where eastern and western time isn't 3 hours apart
jbrot 2y ago
The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?
- andreareina 2y ago
  Maybe a cross-timezone interaction? 23:00 pacific is 02:00 eastern (most days)
  - password4321 2y ago
    Right, the transition to daylight savings at 2AM in the Eastern time zone occurs at 11PM in the Pacific time zone; there is one less hour's difference between the time zones until the Pacific time zone also springs forward three hours later.
- MzxgckZtNqX5i 2y ago
  Towards the bottom, it states: It turns out that the Pacific Time Zone is the only one where the bug caused a user visible difference because: 1. Daylight saving time starting or ending changes the time zone offset by just one hour. 2. The bug only has an effect when the difference in the number of hours goes from less than a day to at least a day, or vice versa (e.g. 23 to 24 or 24 to 23). The only hour of the day that satisfies those two conditions is 11:00pm, and the only time zone where daylight saving time starts and ends at 11:00pm is the Pacific Time Zone.
  - deleted 2y ago
    [deleted]
  - jp57 2y ago
    The article may state it, but it's not true. US DST starts and ends at 2am in every time zone. It doesn't start at 2am in the east, 1 central, 12 west, 11 pacific.
- dustincoates 2y ago
crote 2y ago
It does make me wonder how many bugs like these exist in the average codebase. In this case there was an "unusually large" amount of reports, all coming from the same timezone, all filed at the same time. But imagine getting a single bug report, which doesn't provide a timezone or timestamp and essentially boils down to "I swear it said the wrong date yesterday but it fixed itself!": how much time are you really going to spend trying to reproduce it before closing it with the conclusion that the user was probably just imagining things?
- Moru 2y ago
  This was probably what happened for several years already until this person got curious.
mattbillenstein 2y ago
Clocks roll back at 2am Pacific time just like everywhere else - so the author's explanation seems unsatisfying although I've encountered this type of bug before.
- mjevans 2y ago
  Yeah, as soon as they said 11PM I realized, ` they're using EST as the timezone? ` which would just do it at that time for everyone using the doc? I don't work with raw date objects in JavaScript very much, is that illogical behavior from it's Date object?
  - cpfohl 2y ago
    It’s totally feasible; if the server is using JS and is located in ET the parsed Date tends to be converted internally to local zone (very frustrating). The Temporal spec[1] should alleviate a lot of the JS induced pain. Knowing how to correctly store and manipulate time data, however is a completely separate issue that even really experienced engineers can easily mess up, even with solid STD lib support. 1: https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/
- cortesoft 2y ago
  Yeah, I was waiting for the author to mention the unstated premise that the software was using Eastern time as the default.
- mannykannot 2y ago
  I thought the same, but I was not sure, so I searched for the answer, and surely the NIST page "Daylight Saving Time Rules" [1] would be definitive? Unfortunately, its statement of the rule [2] seems ambiguous, in that it uses '2 a.m.' without qualifying it as local time (though the example does.) Is there a rule saying that times expressed as a.m. (or p.m., I suppose) are always local time (in whatever context they appear, which could also be a cause of ambiguity) unless explicitly qualified otherwise? [1] https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst https://www.nist.gov/pml/time-and-frequency-division/popular... [2] At present, daylight saving time in the United States begins at 2:00 a.m. on the second Sunday of March (at 2 a.m. the local time time skips ahead to 3 a.m. so there is one less hour in that day) [and] ends at 2:00 a.m. on the first Sunday of November (at 2 a.m. the local time becomes 1 a.m. and that hour is repeated, so there is an extra hour in that day.)
ajennings 2y ago
This reminds me of a bug I created where the calendar showed only 30 days in March. I took the number of hours in the month, divided by 24, and rounded down. The bigger problem was that I couldn't replicate it because I was in Arizona (which doesn't observe DST). Only users outside of Arizona were seeing the bug.
mjtardiff 2y ago
Keep time and calculate intervals in epoch time, for sure. But the DST/ST switch happens at 02:00 local time on the date of the switch (always a Sunday morning in the US), and so since the OP points out that the bug only happens when DST switches at 23:00 PT…that’s why. The code was doing time-switching wrong in all zones. But as another poster points out, when a server lives in one time zone and is used in another, all hell can easily break loose when deciding what to show the local user.
sixthDot 2y ago
Anyway, kill the DST with fire.
- Am4TIfIsER0ppos 2y ago
  Only if we don't move to permanent summer time.
jakub_g 2y ago
I once came across a similar bug in a popular JS lib, only in Russian timezones, only in some browsers, only on Windows. (It happened due to Russia changing their timezones). https://github.com/yui/yui2/pull/15 https://github.com/yui/yui2/pull/15
- tilt_error 2y ago
  Makes sense since the Russians have been fiddling with time and seems to have turned it back to 1962.
yuliyp 2y ago
My favorite DST bug was a system that was supposed to run every few seconds taking a nap for an hour. It was an event loop thingy that had a few different types of tasks it might do. When it finished one of those tasks it'd record (in time-zone-local time) the time it completed it. When the event loop ran, it'd check that timestamp against now to see whether the task needed doing. In comes the DST rollback. At 1:59 AM Pacific Daylight time the task ran. At 2:00 AM Pacific Daylight time the time changes to 1:00 AM Pacific Standard time. For the next hour it just sees "ooh 1:01 AM is not more than 1 minutes after 1:59 AM, I'm going to sleep. 1:02 AM is not more than 1 minute after 1:59 AM..." and ends up falling behind for that hour until it magically fixes itself at 2:01 AM Pacific Standard Time
- russdill 2y ago
  All such delays should be done uses monotonic clocks. This simplistic solution runs still into problems when you have long delays, especially if the system suspends and/or power cycles. Or if you want the interval to always expire at some wall clock aligned time, such as every half hour on the half hour.
  - yuliyp 2y ago
    A monotonic clock is a bit trickier when dealing with timestamps being written to / read from a separate database, but I agree with the sentiment. Hence why the chosen implementation was buggy :-)
    - russdill 2y ago
      I've commonly seen a kick the can down the road type of solution to issues like these, especially in vehicle systems where a monotonic clock is always used but a entry is included that gives a mapping between wall clock and monotonic if it's available.
iwontberude 2y ago
> It formats the time as “tomorrow”… [clown emoji] Unnecessarily negative IMHO to implicitly call the person who came before you a clown, especially for a bug which is so trivial.
tomeraberbach 2y ago
Hey folks! I appreciate all the comments. Some of them made me realize I had some mistakes in the article. I went ahead and updated some of the content, and also added some notes explaining what I changed. Thanks for the feedback :)
kinderjaje 2y ago
Wow, that’s a tricky bug! Time zones can be so confusing. Glad you figured it out and fixed it. Do you think this could happen in other time zones too?

76 points by tomeraberbach 2y ago

I’m having a hard time following how such naive time handling became part of a Google product. Pick an epoch for timekeeping. Timezones are a display issue.

crote 2y ago
No, it isn't. That approach works fine for things like logging where are your timestamps are in the past, but the moment you have to deal with future timestamps it leads to some truly horrible issues when some political leader decides to change the definition of the timezone. Suddenly all your future epoch-based datetimes are representing the wrong wall clock time...
- londonlawyer 2y ago
  [dead]
- mulmen 2y ago
  Timekeeping is always epoch based. When the definition changes you update the display code. There’s no way to write code today that accounts for future changes in local time.
  - hansvm 2y ago
    That's the same kind of mentality that kept Google Calendar from being able to schedule a monthly meeting on the last day of the month. If you scheduled it on the 31st, the tool would happily accept that 5 months each year wouldn't have your monthly meeting. Suppose I have an 8am alarm to wake up in the morning. I want that to happen once per day in my current local timezone. If I change locations, the epoch I'm being alarmed at should change. If I travel quickly enough to experience multiple 8ams, I only want one of them (the first one). If laws change to give me multiple 8ams in a single locale, it's ambiguous which one I want. How your alarm app handles that varies, but you should do _something_ (flag the situation in the app, pick one (if one of them is about the same epoch as the previous alarm, maybe pick that one), ...). For calendars you have probably a different set of choices. If all participants are in the same time zone, you probably want the meeting to move as regulations change the definition of 8am. If they're in different time zones which all practice daylight savings and the meeting doesn't conflict with any of the 1-2am haunted hours then the meeting should probably move with daylight savings, reference the local time as it was defined when the meeting was created, and not move as some dictator redefines a time zone (becoming a cross between a display issue and actually considering local time). If you don't know anything as a calendar app about the participants, there will be edge cases where you make bad decisions, so you either accept that or flag the ambiguity when appropriate. And so on. If we can convince everyone to switch to some kind of atomic time without leap seconds I'd be tickled pink. That's not the world we live in though.
    - mulmen 2y ago
      That’s the difference between the 31st and the last day of the month. It’s a UX issue, not a timekeeping issue.
  - toast0 2y ago
    Storing epochs for future times that are specified in local time usually isn't enough considering that local time zones change. If you only deal in times and time zones where time zone changes are announced far enough in advance that zone changes can be processed before any events they effect are in the system, it doesn't matter. But if people schedule things years out in countries with reasonable notice, or weeks out in countries where there's a lack of notice, there's a good chance of doing things wrong. To accomidate these future dates, you should store the localtime and you should also store the offset and/or an epoch determined at time of storage. When rules change, you should evaluate future events and for events where the calculated epoch changes, storing and using the new epoch is a sensible default --- you should ideally show the user a summary of changes, so they can adjust if they have things that were entered in local time for convenience but are actually scheduled in a different zone.
- Dylan16807 2y ago
  But the context of the article was logging and purely a display issue.
saagarjha 2y ago
Googlers are not all timekeeping experts, nor are they all capable of summoning that knowledge at all times when writing code.
- mulmen 2y ago
  It just seems like something Google would have solved in a general sense. It’s a hard problem, asking everyone to get it right is unrealistic, clearly.

Moru 2y ago

Can we talk about all the problems with dates formated as "today", "tomorrow" or "2 hours ago" when trying to figure out how far apport two log-events happened? I at least want an OPTION to set that I want all dates down to the second exactly when they happened... And in a standard format with Y-M-D H:m:s that can sort naturally. The most significant part first, the least significant last.

noja 2y ago
Yeah at least I want a mouseover to see the real timestamp, and the column to be sortable.
stephen_g 2y ago
The absolute worst are ones like “last month”, “last week” or “earlier this week” - almost absolutely useless! Especially for logs of things that happened at work, I extremely frequently want to know the day and date something happened, but that style obscures that sometimes to the point where you can’t even tell which week it was!
- Moru 2y ago
  And if you save something and need to look it up a year later it's even less useful. Last week computed from save date? File save date changed because zip-file didn't save the date? Well, now it's worse than useless, now it's missleading.
- bigiain 2y ago
  I consider those as "management oriented time deltas". Usually specifically requested by Project Managers because they're so imprecise that they can avoid being held responsible for anything...
- Aardwolf 2y ago
  I also hate "1 year ago" when it was actually 23 months ago
  - tonyhart7 2y ago

et-al 2y ago

> Normally I would have dismissed that as a coincidence, but daylight saving time also ended at 11:00pm (PT) on November 7! Huh? Unless I'm mistaken, Daylight Saving ended at 2am local time on Nov 7, 2021. Was the bug that Day Saving is internally set based on Eastern Time (i.e. 2am ET / 11pm PT)?

Laughsalot 2y ago
This is my understanding as well. and and Wikipedia backs me up on it [https://en.wikipedia.org/wiki/Pacific_Time_Zone#Daylight_time https://en.wikipedia.org/wiki/Pacific_Time_Zone#Daylight_tim...]. Some of the software I've written _explicitly_ disables scheduling mobile notifications during the transition periods so I was also very confused by that. Your ET speculation makes sense to me. I'll bet that whatever server/containers being used for the backend were running in the Eastern Timezone.
- waffletower 2y ago
  Normalizing to a zoned date (vs. an epoch representation) during a transition period is problematic. During the transition periods (unique to each daylight time zone) the temporal distance between timezones changes (increases or decreases by 1) temporarily.
cortesoft 2y ago
Sounds like the library that is converting their internal eastern time representation of the datetime to local time is determining the daylight savings time before converting. Or it is just assuming a standard offset, not taking into account the 6 hours a year where eastern and western time isn't 3 hours apart

jbrot 2y ago

The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?

andreareina 2y ago
Maybe a cross-timezone interaction? 23:00 pacific is 02:00 eastern (most days)
- password4321 2y ago
  Right, the transition to daylight savings at 2AM in the Eastern time zone occurs at 11PM in the Pacific time zone; there is one less hour's difference between the time zones until the Pacific time zone also springs forward three hours later.
MzxgckZtNqX5i 2y ago
Towards the bottom, it states: It turns out that the Pacific Time Zone is the only one where the bug caused a user visible difference because: 1. Daylight saving time starting or ending changes the time zone offset by just one hour. 2. The bug only has an effect when the difference in the number of hours goes from less than a day to at least a day, or vice versa (e.g. 23 to 24 or 24 to 23). The only hour of the day that satisfies those two conditions is 11:00pm, and the only time zone where daylight saving time starts and ends at 11:00pm is the Pacific Time Zone.
- deleted 2y ago
  [deleted]
- jp57 2y ago
  The article may state it, but it's not true. US DST starts and ends at 2am in every time zone. It doesn't start at 2am in the east, 1 central, 12 west, 11 pacific.
dustincoates 2y ago

crote 2y ago

It does make me wonder how many bugs like these exist in the average codebase. In this case there was an "unusually large" amount of reports, all coming from the same timezone, all filed at the same time. But imagine getting a single bug report, which doesn't provide a timezone or timestamp and essentially boils down to "I swear it said the wrong date yesterday but it fixed itself!": how much time are you really going to spend trying to reproduce it before closing it with the conclusion that the user was probably just imagining things?

Moru 2y ago
This was probably what happened for several years already until this person got curious.

mattbillenstein 2y ago

Clocks roll back at 2am Pacific time just like everywhere else - so the author's explanation seems unsatisfying although I've encountered this type of bug before.

mjevans 2y ago
Yeah, as soon as they said 11PM I realized, ` they're using EST as the timezone? ` which would just do it at that time for everyone using the doc? I don't work with raw date objects in JavaScript very much, is that illogical behavior from it's Date object?
- cpfohl 2y ago
  It’s totally feasible; if the server is using JS and is located in ET the parsed Date tends to be converted internally to local zone (very frustrating). The Temporal spec[1] should alleviate a lot of the JS induced pain. Knowing how to correctly store and manipulate time data, however is a completely separate issue that even really experienced engineers can easily mess up, even with solid STD lib support. 1: https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/
cortesoft 2y ago
Yeah, I was waiting for the author to mention the unstated premise that the software was using Eastern time as the default.
mannykannot 2y ago
I thought the same, but I was not sure, so I searched for the answer, and surely the NIST page "Daylight Saving Time Rules" [1] would be definitive? Unfortunately, its statement of the rule [2] seems ambiguous, in that it uses '2 a.m.' without qualifying it as local time (though the example does.) Is there a rule saying that times expressed as a.m. (or p.m., I suppose) are always local time (in whatever context they appear, which could also be a cause of ambiguity) unless explicitly qualified otherwise? [1] https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst https://www.nist.gov/pml/time-and-frequency-division/popular... [2] At present, daylight saving time in the United States begins at 2:00 a.m. on the second Sunday of March (at 2 a.m. the local time time skips ahead to 3 a.m. so there is one less hour in that day) [and] ends at 2:00 a.m. on the first Sunday of November (at 2 a.m. the local time becomes 1 a.m. and that hour is repeated, so there is an extra hour in that day.)

ajennings 2y ago

This reminds me of a bug I created where the calendar showed only 30 days in March. I took the number of hours in the month, divided by 24, and rounded down. The bigger problem was that I couldn't replicate it because I was in Arizona (which doesn't observe DST). Only users outside of Arizona were seeing the bug.

mjtardiff 2y ago

Keep time and calculate intervals in epoch time, for sure. But the DST/ST switch happens at 02:00 local time on the date of the switch (always a Sunday morning in the US), and so since the OP points out that the bug only happens when DST switches at 23:00 PT…that’s why. The code was doing time-switching wrong in all zones. But as another poster points out, when a server lives in one time zone and is used in another, all hell can easily break loose when deciding what to show the local user.

sixthDot 2y ago

Anyway, kill the DST with fire.

Am4TIfIsER0ppos 2y ago
Only if we don't move to permanent summer time.

jakub_g 2y ago

I once came across a similar bug in a popular JS lib, only in Russian timezones, only in some browsers, only on Windows. (It happened due to Russia changing their timezones). https://github.com/yui/yui2/pull/15 https://github.com/yui/yui2/pull/15

tilt_error 2y ago
Makes sense since the Russians have been fiddling with time and seems to have turned it back to 1962.

yuliyp 2y ago

My favorite DST bug was a system that was supposed to run every few seconds taking a nap for an hour. It was an event loop thingy that had a few different types of tasks it might do. When it finished one of those tasks it'd record (in time-zone-local time) the time it completed it. When the event loop ran, it'd check that timestamp against now to see whether the task needed doing. In comes the DST rollback. At 1:59 AM Pacific Daylight time the task ran. At 2:00 AM Pacific Daylight time the time changes to 1:00 AM Pacific Standard time. For the next hour it just sees "ooh 1:01 AM is not more than 1 minutes after 1:59 AM, I'm going to sleep. 1:02 AM is not more than 1 minute after 1:59 AM..." and ends up falling behind for that hour until it magically fixes itself at 2:01 AM Pacific Standard Time

russdill 2y ago
All such delays should be done uses monotonic clocks. This simplistic solution runs still into problems when you have long delays, especially if the system suspends and/or power cycles. Or if you want the interval to always expire at some wall clock aligned time, such as every half hour on the half hour.
- yuliyp 2y ago
  A monotonic clock is a bit trickier when dealing with timestamps being written to / read from a separate database, but I agree with the sentiment. Hence why the chosen implementation was buggy :-)
  - russdill 2y ago
    I've commonly seen a kick the can down the road type of solution to issues like these, especially in vehicle systems where a monotonic clock is always used but a entry is included that gives a mapping between wall clock and monotonic if it's available.

iwontberude 2y ago

> It formats the time as “tomorrow”… [clown emoji] Unnecessarily negative IMHO to implicitly call the person who came before you a clown, especially for a bug which is so trivial.

tomeraberbach 2y ago

Hey folks! I appreciate all the comments. Some of them made me realize I had some mistakes in the article. I went ahead and updated some of the content, and also added some notes explaining what I changed. Thanks for the feedback :)

kinderjaje 2y ago

Wow, that’s a tricky bug! Time zones can be so confusing. Glad you figured it out and fixed it. Do you think this could happen in other time zones too?