I would opt for programmatic conversion of the timestamps to your required time zone over setting the timezone of the AF client system to something other than the local timezone for it's actual location. The TimeZoneInfo.ConvertTime method looks probably like the best option for this.
1 of 1 people found this helpful
In general i'd say: keep any system in UTC, and only use local timezones for exposing data to clients.
UTC keeps you away from DST issues and the like which we do have in central europe.
3 of 3 people found this helpful
Building upon John and Roger's answers, which are both correct ... let's first take AFSDK out of the picture. How would you make your app handle time zones given that on a given workstation some user may have changed the local time zone? Short of adding in something like NodaTime, the limitation of a DateTime.Kind of Unspecified is that either it means (a) the date time value is in some unknown time zone, or (b) the date time value is in some known time zone that is neither UTC nor local. The problem with (b) is that two different Unspecified's are not necessarily from the same time zone.
The safe way to proceed is that regardless of the workstation's local time zone is for you to convert all date times to UTC. So, yes, you would use TimeZoneInfo's Convert methods, but more specifically the ConvertTimeToUtc and ConvertTimeFromUtc methods. Once you have a DateTime with a Kind of Utc, you can create an AFTime with that UTC-based value.
Your efforts don't have to worry about the stuff in the middle. Your concern is on the very first and last stages. The first stage is grabbing the time. Whichever workstation, grab the time in UTC. If you must display that immediately, you will need to convert it to CET, if CET is not currently the local time zone. If CET is the local time zone, then using the ToLocalTime() method works. But you use the UTC time when working with AFSDK in the middle.
The last stage is when you read values via AFSDK and you wish to display those values to the user in CET. Use the AFTime's UtcTime method to convert to a DateTime with Kind of Utc. Then you would convert that once again to the desired time zone.
It's not rocket science, but the burden is on you. Also this works for your custom app, where you have total control over the presentation system, but may not work as desired using PSE because PSE only displays date times in local time.
thank you all for your hints.
I found a solution which is quite straight forward, but it seems to work well.
I have to convert timestamps from CET (GMT+1) to UTC and vice versa. Both Timezones have no Daylight saving support. The only difference is, that CET is one hour ahead of UTC.
So I do my conversion simply by adding or subtracting 3600 seconds. The only thing, I have to keep an eye on is, that I always work with the UTC-Represantaion of AFTime and DayTime.
CET --> UTC
DateTime tmpDateTime = new DateTime(InTs.getJahr(), InTs.getMonat(), InTs.getTag(), InTs.getStunde(), InTs.getMinute(), InTs.getSekunde(), DateTimeKind.Utc);
tmpDateTime = tmpDateTime.AddSeconds(-3600);
OutTs = new AFTime(tmpDateTime);
UTC --> CET
DateTime tmpDateTime = InTs.UtcTime;
tmpDateTime = tmpDateTime.AddSeconds(3600);
OutTs = new TBAS_DateTimeCS();
Cheers & thanx