TimeZone2 - first impressions

Posted Wed, Oct 4 2006 22:26 by bill
Kathy Kam  asked for feedback on Timezone2, so tonight I decided to have a bit of a play and these are my first impressions// partial code review:
  1. ConvertTimeBySystemTimeZoneId  could the name be any longer ?  I think this should probably just be an overload  of ConvertTime .

  2. When using ConvertTimeBySystemTimeZoneId it would be nice to be able to easily refer to the local time zone, e.g. "local" or similar string inst4ead of having to use ConvertTime with two TimeZones.

  3. the same for (2) in any of the api that takes a time zone id

  4. time zone id strings should allow the abbreviated form.  The list from time and date .com is a pretty good starting point.  (note the forms of CST and EST that refer to Australian times should be ignored as they cause an ambiguity with the American ones, and the correct form of AEST is already listed in that list :) )

  5. FindSystemTimeZoneById should return the same time zone if called multiple times instead of a different instance each time.

  6. because of 5, if you try to convert a time using ConvertTimeBySystemtimeZoneId using the local timezone id and a date time with the Kind set as Local, it fails, because of a failed reference check to see if the TimeZone2 is the same as the static Local one that is cached.

  7. related to 5, if the user wants a new instance of a TimeZone2 a clone method, or a constructor that takes a TiemZone2 etc, should be exposed, although this is only likely to be useful in the CreateCusotmtimeZone overloads as TimeZone2 is practically read only.

  8. because the static Local is cached, either a method to refresh should be exposed, or a check made in the property get to ensure the Timezone has not changed , or it should listen to system events. However as this is static, listening to system events can have side effects as they will not be released until the app domain is released.  My preference would be to make an efficient as possible test in the property get, and leave any caching up to the consumer.
  9. FindSystemTimeZoneById would be more friendly if it had an enum for the time zones, based on the abbreviations.
  10. Likewise these api that take a zone Id, should accept the daylight string as well.
  11. Similar to 9, a list of string constants in a class, such as KnownTimeZones would be very helpful.  I hate string literals in my code, and they should only be there because I've stepped outside the box ;)
  12. It would be nice if .NET distanced itself a bit further from the OS, and provided the basic known time zones as a *backup* should they not be found in the registry.  That is the base of this API should be platform independent, but it should use the platform configuration if it is there, just like any "setting" should.

I think that's the majority of the things that came to mind in the very brief play and investigation I had.  Other than that the class is very cool.  Seems to work well.  What I would like to see next are some TimeZone2 operations for DateTime, such as adding n hours to a DateTime and ensuring that is adjusted as needed due to DayLight Savings changes etc.

And of course then the final bit would be to include this with DateTime in a structure that will read and write nicely from XML preserving the time zone (ideally as abbreviated string for known TimeZones), and even have a SQL CLR type ??
Filed under: ,

Comments

# re: TimeZone2 - first impressions

Wednesday, October 04, 2006 3:15 PM by KathyKam

Hey @Head,

This is some great feedback! I'll probably address all of them in my next posting! :)

There is some quick responses to your points above:

5: FindSystemTimeZoneById is not reaturing a fresh instance everytime.

6: The behaviour you are seeing is a known issue that will be fixed in the RTM version.

8: TimeZone2.ClearCachedData allows you to clear the cached Data.

Thanks,

Kathy

# re: TimeZone2 - first impressions

Wednesday, October 04, 2006 7:54 PM by bill

Hi Kathy,

Re 5, oh yes it is !!

Dim tz1 As TimeZone2 = TimeZone2.FindSystemTimeZoneById("AUS Eastern Standard Time")

Dim tz2 As TimeZone2 = TimeZone2.FindSystemTimeZoneById("AUS Eastern Standard Time")

If tz1 Is tz2 Then ' returns False

The problem is inside TryGetTimeZone, jsut look for all the "new"'s in there ;)

RE 6: it's because of 5 :)

Re 8:  Cool !! Sorry I didn't notice it, my bad :(  

Thanks,

Bill.

# re: TimeZone2 - first impressions

Wednesday, October 04, 2006 8:21 PM by bill

more thoughts on 8.

As it stands the caller has to know when to call TimeZone2.ClearCachedData, which is pretty hard for them to do while only using the framework.

Looking at what is cleared in that, the only one of any real significnace I think is the Local property. that is, through standard window Ui's it's easy ot change the current time zone.  UTC won't change, and althohg any cached system time zonez might change, when they are changed, it's not a standard windows operation.

So the question is is the overhead of calling  GetDynamicTimeZoneInformation and comparing the data with the cached Local timezone2 so significant that we cut functionality for the sake of performance ?  

Personally I would think that functionality is more important than performance here, and should the perf be an issue, the caller can cache TimeZone2.Local themselves. hence haivng Timezone2.Local *always* check to see if ti has changed would be the better design IMNSHO :)

# Mind Gravy » Blog Archive » links for 2008-05-17

Saturday, May 17, 2008 7:33 AM by Mind Gravy » Blog Archive » links for 2008-05-17

Pingback from  Mind Gravy  » Blog Archive   » links for 2008-05-17