4 ms·

How do you handle DST? Do any of these locations run 24/7? I've found DST to be a compelling case for storing everything in UTC. Times get converted to the c

• Khao 11y ago
  We simply ignore DST. For example let's take a recurring event that happens every Wednesday at 6pm for 10 weeks. In the middle of those 10 weeks, this timezone enters DST. By saving the series' time as 6pm EST in the database, we can save all the individual occurences without having to do any check for DST changes in the middle of the series. The users are simply interested in knowing when their yoga class is, the class is at 6pm, that's it. Before or after DST change, it's still 6pm. Edit : Even if we had locations that were running 24/7, I don't think there would be any issue. An event that starts at 10pm and ends at 4am after a DST change? Any good datetime library will tell you that the event runs for either 7 or 5 hours, when calculating difference between those 2 datetimes when knowing the proper timezone. We're using C# and the standard .Net datetime library is one of the best I've ever worked with.
• icebraining 11y ago
  Funny; DST is exactly what made me doubt the rule of storing everything in UTC. We've had a lot of problems with a platform that stores recurring events as UTC date + time delta (eg. 1 week). What the users want is an event that happens every week on a certain weekday and time, in their timezone - they don't care if that falls on various times in UTC throughout the year. Of course, that's specific for recurring events/schedules.
  • deleted 11y ago
    [deleted]