6

I have just started working with NodaTime. In my app, the user creates an event and chooses a time zone. Regardless of whether I use the BCL (Windows) time zone list or the TZDB (Olson) list (and do not mix them!), I need to persist the id of the time zone to my database so that I can later recreate the timezone-aware time.

Given that timezone ids appear to be somewhat arbitrary and are not an ISO standard, can I rely on always finding that id in future when I call GetZoneOrNull?

I am assuming that the GetZoneOrNull method is the defence against that happening; that is, when it is passed an id that does not exist in its own Ids collection. My question is: if an id has been retrieved from the Ids collection, can I trust that GetZoneOrNull will never in future return null?

But if an Id can disappear from history, what is the best strategy to deal with that?

Rob Kent
  • 5,183
  • 4
  • 33
  • 54

1 Answers1

6

Obviously, if you switch between windows' timezones and TZDB then the timezone Ids will be different. Olson timezone Ids are meant to be stable and should not change. Even though I say that, there have been changes in the past, but the old Ids still exist and are aliases for the new ones. All the "region/city" ids are the new style and that scheme was chosen so that they should never have to change again. Old ids were sometimes named based on legal names of timezone which are subject to change.

We are storing the Olson Id of the timezone in a table on my current project.

I can't speak for windows timezone ids.

Jeff Walker Code Ranger
  • 4,634
  • 1
  • 43
  • 62
  • I will be choosing either TZDB or Windows, leaning towards Olson to be honest just in case I need to speak to the outside world. I like the fact that they alias the old ids to the new ones, which makes the problem go away I think. I am not sure if Windows will adopt the same convention but you would like to think so. Because of that doubt, I am going to use Olson. Thanks. – Rob Kent Nov 09 '12 at 22:03