none
Getting the proper Bias RRS feed

  • Question

  • Hello,

    I m trying to eliminate the use of WMI in some legacy code

    My problem is with getting the proper value for the time zone offset

    WMI:

    Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
    Set colTimeZone = objWMIService.ExecQuery("Select * from Win32_TimeZone")

    For Each objTimeZone in colTimeZone
       intTZBiasInMinutes = objTimeZone.Bias 
    Next

    Registry:

    HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ -> Bias

    The WMI solution says +120

    The Registry says -120

    According to these:

    https://msdn.microsoft.com/en-us/library/reportservice2010.timezoneinformation.bias.aspx

    https://msdn.microsoft.com/en-us/library/aa394498(v=vs.85).aspx

    They should both return the same value e.g. UTC = local time + bias

    What am I doing wrong ?

    Tuesday, March 21, 2017 8:18 PM

Answers

  • OK.  All coordinates are relative to the observatory in Greenwich and are measured in absolute minutes east or west of Greenwich.  For the current time we take the offset and add the DST bit then either add or subtract from UCT.   If we are east we subtract and west we add.

    Windows method: UCT +- (TZ + DST)
    CIM method: UCT + (TZ - DST)

    For WMI the east west is incorporated into the setting and in the registry it is derived from the locale.  The registry and Windows can handle more variations in locale than the WMI method but both work the same under almost all normal circumstances.

    Normally we would set the offset and DST and locale to calculate the time.

    Since DST is only used in western countries the simple formula (UCT + TZ) will work always.  Mostly system clocks are set to UCT and the displayed time is derived.  You can log in to an RDS server anywhere and set your preferred locale and it won't effect any calculations the store or present time correctly.

    Most good databases store time as UTC but some older ones use local time plus time zone information.

    UTC is the same anywhere on the earth.  Local time is based mostly on the sun plus cultural and political preferences.  These can change but UTC will always be relevant.


    \_(ツ)_/

    Wednesday, March 22, 2017 6:40 AM

All replies

  • Yes.  That is how it works.


    \_(ツ)_/

    Tuesday, March 21, 2017 9:14 PM
  • Why the difference in results then ?
    Wednesday, March 22, 2017 5:34 AM
  • Different algorisms.


    \_(ツ)_/

    Wednesday, March 22, 2017 6:20 AM
  • OK.  All coordinates are relative to the observatory in Greenwich and are measured in absolute minutes east or west of Greenwich.  For the current time we take the offset and add the DST bit then either add or subtract from UCT.   If we are east we subtract and west we add.

    Windows method: UCT +- (TZ + DST)
    CIM method: UCT + (TZ - DST)

    For WMI the east west is incorporated into the setting and in the registry it is derived from the locale.  The registry and Windows can handle more variations in locale than the WMI method but both work the same under almost all normal circumstances.

    Normally we would set the offset and DST and locale to calculate the time.

    Since DST is only used in western countries the simple formula (UCT + TZ) will work always.  Mostly system clocks are set to UCT and the displayed time is derived.  You can log in to an RDS server anywhere and set your preferred locale and it won't effect any calculations the store or present time correctly.

    Most good databases store time as UTC but some older ones use local time plus time zone information.

    UTC is the same anywhere on the earth.  Local time is based mostly on the sun plus cultural and political preferences.  These can change but UTC will always be relevant.


    \_(ツ)_/

    Wednesday, March 22, 2017 6:40 AM
  • Thank you very much for the detailed explanation

    Wednesday, March 22, 2017 6:58 AM