I’m having good success with using TimeZone.Current.SecondsFromGMT and making corrections to GMT. However, when the system is up and running and the host OS clock is changed, the value returned by TimeZone.Current.SecondsFromGMT doesn’t update.
Is there a method for refreshing the application to re-fetch the local DateTime/TimeZone data?
Why would you need to make corrections?
DateTime manages this for you
Re-fetch is DateTime.Now that returns a datetime on the local settings
That does work, but if you refetch TimeZone.Current.SecondsFromGMT it still reflects the old TimeZone, not the one newly set in the OS. The DataTime.Now works, but you have to relaunch the app for TimeZone.Current.SecondsFromGMT to generate an updated value.
It sounds like TimeZone.Current isn’t returning the actual current time zone when the user changes time zones. My guess would be a caching system.
It is very possible for a user to change time zones while running, for example this happens when traveling with a laptop.
I recall having to write functions to handle this scenario for Task Timer, so it happens more frequently than you might think.
Does the abbreviation change?
Xojo uses the “current” instead of “autoUpdatingCurrent” perhaps?
Scroll down a little.
I use Xojo to abstract myself from knowing the internals of the system specific APIs. Though I have the capability to understand them, the purpose of Xojo is to handle these details.
If Xojo isn’t returning the current, actual, right now timezone with TimeZone.Current then they need to either update their documentation or fix the framework.
The current time zone.
I haven’t tested the functionality, I’m just making a point because you are trying very hard to dismiss this issue.
@William_Reynolds I can’t reproduce your results when changing the Time Zone via System Preferences. However, they are re-using the object because I see my manually cached one update to the current time zone. Honestly, that’s kind of worse.
This behavior contradicts that of DateTime.Now which returns an immutable object. One would expect TimeZone.Current to return a new object representing the current time zone.
Missed the mark on consistency throughout API 2.0 there.
I didn’t mention it’s happening on Linux/RPi, which may or may not make a difference. Knowing it’s happening and that nobody has pointed out an obvious mistake. Thanks for helping me explore this - and Tim I totally agree, if the docs say TimeZone.Current.SecondsFromGMT, then ‘.Current.’ is what to expect. (but all complaining aside, I couldn’t do my job w/out XOJO!)
Do you get a different behavior on Linux with the test project I created?
Just pulled it down and ran it. Will try it on the RPi shortly - thanks!
EndPoint_GMT_OFFSET = TimeZone.Current.SecondsFromGMT
System.DebugLog(EndPoint_GMT_OFFSET.ToText)
If you execute this in a loop, change the OS clock-timezone, you’ll see the value doesn’t change, but if you quit and rerun the app, well then it does. This isn’t the end of the world - just not anticipated.
Maybe Xojo is reading the “Get_current_Timezone()” only once at “Framework_Runtime_Init()” and storing it instead of a new one at every “Get_Current_Date_Time()”?
Maybe in this case the object is not storing the current timezone, it’s just storing the UTC0:00 version of it and using an external shared timezone for ALL them! And yes, this is not correct.