timezone with data for 2008

Topics: Developer Forum, User Forum
Mar 22, 2008 at 4:23 AM
does the newer version contain definitions from olson 2008 data files?
Coordinator
Mar 26, 2008 at 8:54 PM
Hi Shahzad, the latest data is tzdata2007k. I am about to update PublicDomain now, so I will add the latest 2008 data...

Kevin
Mar 27, 2008 at 4:56 AM
i will be waiting for that. I think we should compile that data in resource files rather than in dll or exe.
it would be easier to update. There have been some posts regarding this matter.


schizoidboy wrote:
Hi Shahzad, the latest data is tzdata2007k. I am about to update PublicDomain now, so I will add the latest 2008 data...

Kevin

Coordinator
Mar 27, 2008 at 5:51 PM
Edited Mar 27, 2008 at 5:51 PM
Hi Shahzad,

The latest version 0.2.43.0 now has tzdata2008b:

http://www.codeplex.com/publicdomain/Release/ProjectReleases.aspx?ReleaseId=12031

The problem with resource files is then PublicDomain won't be able to run in a Partial Trust environment, like hosted apps, because it will need the FileIOPermission. I also thinking turning tzdata into C# code and compiling it right into the assembly is much, much faster :) I understand your concern though, and the code changes to read from a tzdata directory would not be too hard, so it is an option if you would like to work on it.

Thanks!
Kevin
Mar 28, 2008 at 6:14 AM
Thanks kevin.

I would like to work on this option but i need a few details

What do u mean by this?
  • also thinking turning tzdata into C# code and compiling it right into the assembly is much, much faster :)*

right now TzData is being cached in memory , in the form of object. do u want to be emitted into an assembly at run time? OR wat ?



schizoidboy wrote:
Hi Shahzad,

The latest version 0.2.43.0 now has tzdata2008b:

http://www.codeplex.com/publicdomain/Release/ProjectReleases.aspx?ReleaseId=12031

The problem with resource files is then PublicDomain won't be able to run in a Partial Trust environment, like hosted apps, because it will need the FileIOPermission. I also thinking turning tzdata into C# code and compiling it right into the assembly is much, much faster :) I understand your concern though, and the code changes to read from a tzdata directory would not be too hard, so it is an option if you would like to work on it.

Thanks!
Kevin

Coordinator
Mar 29, 2008 at 10:09 PM
Edited Mar 29, 2008 at 10:09 PM
Hey Shahzad,

So, if I understood correctly, you would like a feature so that updating to a new version of tzdata can be done without changing PublicDomain.dll, correct? Right now, the way it works is that I take tzdata and run it through PublicDomainTests.TzDatabaseTests.ReadDatabase. This takes all of the historical data in tzdata and converts it to C# code. I then place this C# code into PublicDomain.TzTimeZone.cs and compile. This has many advantages:

  1. PublicDomain doesn't need any FileIOPermissions because all of the data is compiled in (this is true for embedded resources as well, since those also need FileIOPermission, as well as ReflectionPermission I believe)
  2. It is much faster than read files or resources, interpreting them, caching them, and then looking up time zone information. Instead, since the tzdata has already been "codified," and has caching built-in, so that looking up time zone data doesn't require objectifying the data, nor parsing the data. This is much faster and less memory intensive.

If I understood your question correctly, then all we would save by supporting this feature is that you wouldn't need to re-install PublicDomain.dll. Instead you would over-write the tzdata directory with updated data. I'm not a fan of this approach, because, #1 you need to either carry the tzdata directory everywhere you use PublicDomain (for example, ASP.NET apps, local apps, etc.), and there is still the issue of updating tzdata. If it is packaged directly into PublicDomain, then this seems like the easiest solution. Make resource files is just as difficult, since then you have to package the resource files with PublicDomain.dll, and if you're already updating the resources files, then it should be just as easy to update PublicDomain.dll?

Thanks!
Kevin
Mar 30, 2008 at 8:08 AM
Hi Kevin, Your points are pretty much correct when we talk abt medium trust environment.

I was wondering what would hapeen if PublicDomain.dll is being hosted in Wesbservice. The application will require a restart which any one including me doesnt want.

Another (rather costly solution) is that we should write a utility application that moves calculated TzData (the data which is represented by TzTimeZone.cs) in MySql Db. That db doesnt need to be replica of Oslon. It may have its own schema. But that schema would be simple enough for user to query data easily by passing TimeZone name and/or place name. OffCourse we are getting out of publicdomain here but it could be a solution.
What do u think? Is it possible and a good solution considering Oslon DB?


schizoidboy wrote:
Hey Shahzad,

So, if I understood correctly, you would like a feature so that updating to a new version of tzdata can be done without changing PublicDomain.dll, correct? Right now, the way it works is that I take tzdata and run it through PublicDomainTests.TzDatabaseTests.ReadDatabase. This takes all of the historical data in tzdata and converts it to C# code. I then place this C# code into PublicDomain.TzTimeZone.cs and compile. This has many advantages:

  1. PublicDomain doesn't need any FileIOPermissions because all of the data is compiled in (this is true for embedded resources as well, since those also need FileIOPermission, as well as ReflectionPermission I believe)
  2. It is much faster than read files or resources, interpreting them, caching them, and then looking up time zone information. Instead, since the tzdata has already been "codified," and has caching built-in, so that looking up time zone data doesn't require objectifying the data, nor parsing the data. This is much faster and less memory intensive.

If I understood your question correctly, then all we would save by supporting this feature is that you wouldn't need to re-install PublicDomain.dll. Instead you would over-write the tzdata directory with updated data. I'm not a fan of this approach, because, #1 you need to either carry the tzdata directory everywhere you use PublicDomain (for example, ASP.NET apps, local apps, etc.), and there is still the issue of updating tzdata. If it is packaged directly into PublicDomain, then this seems like the easiest solution. Make resource files is just as difficult, since then you have to package the resource files with PublicDomain.dll, and if you're already updating the resources files, then it should be just as easy to update PublicDomain.dll?

Thanks!
Kevin

Coordinator
May 6, 2008 at 12:41 PM
Hi Shahzad, I'm not clear on this concern you have:


Shahzad wrote:
I was wondering what would hapeen if PublicDomain.dll is being hosted in Wesbservice. The application will require a restart which any one including me doesnt want.


The tz database is only updated every few months, so applying maintenance this often can't be so bad. If you're looking for a 24/7/365 application, then you could certainly write an extension which probed for filesystem changes to tzdata every so often, and if any were found, it would run the database parser and update the in-memory cache.

Kevin