On Wed, Oct 30, 2019 at 3:02 PM Rob Berendt <rob@xxxxxxxxx> wrote:
I'm really into one stop shopping.
With IBM i I can take the time and add the UTC and get another person's time.
With Windows I have to take the UTC, plus determine whether or not I'm in DST, and then get that.
As far as I'm concerned, taking GMT and adding the UTC should give you your system time. Plain and simple.
First of all, UTC *is* GMT. UTC is a newer and more international
term, but they mean the same thing.
You mean the UTC *offset*.
I agree that Windows doesn't make the current UTC offset easily
available for interactive use. It would be almost no trouble for
someone at Microsoft to write a little command that retrieves it (and
translates it) from the registry. Similarly, it would be almost no
trouble at all to expose it as an environment variable.
I think the only reason neither of those has happened is that "normal
users" (who are the overwhelming target audience of Windows) don't
typically need to know that. They *do* often need the correct local
time, and as discussed, Windows does manage that in a fairly friendly,
low-fuss way. MS also provides wrappers for fairly easy programmatic
access, so it hasn't been much of an issue even for programmers.
For the sake of satisfying curiosity, I found out where Windows does
store this information, and it's the variable ActiveTimeBias in the
registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation.
But it's in hex, in minutes, and the opposite sign than how UTC
offsets are normally given. In other words, you add this value to your
local time to arrive at UTC.
From the command line, the quickest way to get this information is
reg query hklm\system\currentcontrolset\control\timezoneinformation
/v activetimebias
For folks in Eastern Time (US & Canada), this value is currently 0xf0,
or 240 in decimal. Local time + 240 minutes = UTC. There is another
variable, Bias, which for this time zone is 0x12c, or 300 in decimal.
Naturally, this one keeps the same value throughout the year.
Given that it's in hex, this is clearly a Western-hemisphere-centric
scheme, because negative numbers look like this: 0xffffffc4 (which
would be 4294967236 as a "naive" (unsigned) decimal, but is really a
4-byte signed value, so -60).
So yeah, that's probably more than anyone wanted to know about the
active UTC offset in Windows, but there you have it.
John Y.
midrange.com
