We decide to schedule a meeting for 10:00 local time on the 5th December 2020. We'll assume we live in Sao Paulo, Brazil and the year is 2015. Let's take the example of Brazil abolishing DST in 2019. Because ISO 8601 uses an offset rather than an actual time zone, you could run the risk that the rules for a time zone change between when a time is captured and when a time occurs. ISO 8601 can fall short for representing times in the future. Or as a local time with a UTC offset: T19:18:46+02:00įor the most part ISO 8601 works well because a local date time can be converted to ISO 8601 format by calculating the UTC offset (e.g. According to ISO 8601 a datetime can be represented as a UTC time: ISO 8601 is a fairly well adopted international standard for representing datetimes. Until 2019, Brazil typically observed DST between the start of November and mid-February Offsets ≠ Time Zone One recent example comes from 2019 when Brazil abolished daylight saving time. Time zones are also influenced by politics, and political decisions have been responsible for many changes to time zones over the years. It's easy to fall into the trap of thinking of time zones as being purely geographical, especially when people usually encounter time zones when travelling between different parts of the world. Regardless of the solution, edge cases like this should be well tested. first occurrence).ĭetermining the correct answer for these scenarios is likely to depend on your specific scenario and the user experience that you want your user to have. Make an assumption about which occurrence to use (e.g.Raise an error and ask the user to refine their input.assume if they input 01:30 which is undefined due to clocks going forward an hour, they probably meant 02:30 Shift the time forwards proportional to the undefined period of time, e.g.Raise an error and force the user to reconsider their input.In a system where local times can be inputted by a user some thought may need to be given to how these two edge cases will be handled. If someone asks you to meet them at 01:30 local time, which 01:30 do they mean? The first one or the second one? At the point where DST ends local time is ambiguous between 01:00-01:59.At the point that DST starts local time is undefined between 01:00-01:59.There are a few implications of DST which can add to the edge cases when dealing with time: The left hand graph shows the start of DST in March where the clocks go forward by an hour, and the right hand graph shows the end of DST in October where clocks go back an hour. The start and end of DST can be represented visually as follows: Transitioning to/from daylight savings in the UK In the UK, we observe DST between the end of March and the end of October: DST starts at 01:00 on the last Sunday in March when clocks will go forward by 1 hour, and ends on the last Sunday in October at 02:00 where clocks will go back by 1 hour. Some countries may observe DST in certain regions but not in others. Local Time can be Undefined and Ambiguousīefore considering the complexity of time zones, its first worth considering the issues that can exist within local time.ĭaylight Saving Time (DST) is observed in many different parts of the world. This talk has since motivated me to better understand the challenges and what we should consider when design systems to better deal with the challenges of time zones.ĭealing with time is easy isn't it? Don't we just set the server to UTC and store everything in UTC? Kind of, but it's a bit more complicated than that. I recently watched a recording of Jon Skeet's Working with Time is Easy conference talk which highlights some of the challenges of dealing with time and provides some guidance on how to deal with time. store or transmit times without running foul of time zones and complications such as daylight saving time. We've all been in a situation where we've had to decide on how we process. Dealing with time and time zones is hard work.
0 Comments
Leave a Reply. |