4 ms·

Spot on. You don't need the UTC at all to be stored. What matters is the local time at the venue. If its a virtual meeting (eg. over Skype) with participants f

Spot on. You don't need the UTC at all to be stored. What matters is the local time at the venue. If its a virtual meeting (eg. over Skype) with participants from multiple time zones, it is safe to assume always one time zone will take precedence over others and time should be saved with respect to that. If its a natural event like a solar eclipse, it can be saved in UTC. There is always one time zone in which the event won't be adjusted. Just use that.

protomyth 12y ago
"There is always one time zone in which the event won't be adjusted. Just use that." I agree with everything except I would modify that statement to be "There is always one location in the which the event won't be adjusted. Just use that." It seems like people are assuming time zone is fixed when it can change. The fixed point is the location which is used to determine the time zone. Natural events are trickier because they have different assumptions than human created events. UTC is probably best for those.
- mark-r 12y ago
  You're correct, the relation between time zones and locations isn't fixed. Unfortunately the time zone databases don't have enough granularity, you're forced to choose the nearest location that shares your current time zone.
  - protomyth 12y ago
    I do love picking Minneapolis or Chicago when I want a ND location (look at North Dakota in the TZ database, we have some funky stuff going on). Looks like this question has some API for that http://stackoverflow.com/questions/16086962/how-to-get-a-time-zone-from-a-location-using-latitude-and-longitude-coordinates http://stackoverflow.com/questions/16086962/how-to-get-a-tim...
angersock 12y ago
No no no--you will add a lot of hairball code if you persist in not UTC. For the virtual meeting, you just localize the time as they query it--this will make your life vastly simpler when, for example, querying over an interval or what have you. UTC is the right answer.
- mark-r 12y ago
  Did you read the article? A specific case was presented where persisting in UTC simply won't work. I still believe that UTC is useful as an intermediary, and persisting in UTC can work if all your times are in the past and all your conversions are done with an up-to-date rule list.
  - angersock 12y ago
    Yeah, read the article. Considering new house rule of UTC for present and past, wall time (?) for future. Person I was responding to gave bad reasoning ("Pick the timezone that matters most") instead of echoing what the article said.

protomyth 12y ago

"There is always one time zone in which the event won't be adjusted. Just use that." I agree with everything except I would modify that statement to be "There is always one location in the which the event won't be adjusted. Just use that." It seems like people are assuming time zone is fixed when it can change. The fixed point is the location which is used to determine the time zone. Natural events are trickier because they have different assumptions than human created events. UTC is probably best for those.

mark-r 12y ago
You're correct, the relation between time zones and locations isn't fixed. Unfortunately the time zone databases don't have enough granularity, you're forced to choose the nearest location that shares your current time zone.
- protomyth 12y ago
  I do love picking Minneapolis or Chicago when I want a ND location (look at North Dakota in the TZ database, we have some funky stuff going on). Looks like this question has some API for that http://stackoverflow.com/questions/16086962/how-to-get-a-time-zone-from-a-location-using-latitude-and-longitude-coordinates http://stackoverflow.com/questions/16086962/how-to-get-a-tim...

angersock 12y ago

No no no--you will add a lot of hairball code if you persist in not UTC. For the virtual meeting, you just localize the time as they query it--this will make your life vastly simpler when, for example, querying over an interval or what have you. UTC is the right answer.

mark-r 12y ago
Did you read the article? A specific case was presented where persisting in UTC simply won't work. I still believe that UTC is useful as an intermediary, and persisting in UTC can work if all your times are in the past and all your conversions are done with an up-to-date rule list.
- angersock 12y ago
  Yeah, read the article. Considering new house rule of UTC for present and past, wall time (?) for future. Person I was responding to gave bad reasoning ("Pick the timezone that matters most") instead of echoing what the article said.