UTC offset for MY when program runs in another time zone

Howard Kaikow · Joined: 04 Oct 2007 Posts: 468

When running a program on a computer in, say, Tokyo, I can get the UTC times
that correspond to the Tokyo times.

However, the program also needs to know the corresponding UTC Time for New
York.

Is there a way to determine the UTC offset in time zone A when a program is
running in time zone B? This must include adjustment for daylight/standard
time.

Archived from group: microsoft>public>vb>winapi

Jim Mack · Joined: 04 Oct 2007 Posts: 735

Howard Kaikow wrote:
> When running a program on a computer in, say, Tokyo, I can get the
> UTC times that correspond to the Tokyo times.
>
> However, the program also needs to know the corresponding UTC Time
> for New York.

UTC is the same in NY as it is in Tokyo. That's the point of UTC --
it's a standard that doesn't vary across the globe.

> Is there a way to determine the UTC offset in time zone A when a
> program is running in time zone B? This must include adjustment for
> daylight/standard time.

For that, look at the Get/SetTimeZoneInformation APIs. The TZI
structure contains the friendly names for a time zone, if any (both
Standard and Daylight) as well as the Daylight start/end dates and
offsets.

This doesn't tell you anything about "New York" or "Tokyo" as such,
but with a little digging you can usually figure it out.

--
Jim Mack
MicroDexterity Inc
www.microdexterity.com

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Jim Mack wrote:
> Howard Kaikow wrote:
>> When running a program on a computer in, say, Tokyo, I can get the
>> UTC times that correspond to the Tokyo times.
>>
>> However, the program also needs to know the corresponding UTC Time
>> for New York.
>
> UTC is the same in NY as it is in Tokyo. That's the point of UTC --
> it's a standard that doesn't vary across the globe.

Smile

>> Is there a way to determine the UTC offset in time zone A when a
>> program is running in time zone B? This must include adjustment for
>> daylight/standard time.
>
> For that, look at the Get/SetTimeZoneInformation APIs. The TZI
> structure contains the friendly names for a time zone, if any (both
> Standard and Daylight) as well as the Daylight start/end dates and
> offsets.
>
> This doesn't tell you anything about "New York" or "Tokyo" as such,
> but with a little digging you can usually figure it out.

Can you? GTZI/STZI only work with the current TZ, no? I've never found a way other
than registry spelunking, and that's pretty dodgy too as you're betting that 1) MSFT
is keeping up with stuff and 2) user is patching.
--
..NET: It's About Trust!
http://vfred.mvps.org

Jim Mack · Joined: 04 Oct 2007 Posts: 735

Karl E. Peterson wrote:
> Jim Mack wrote:
>> Howard Kaikow wrote:
>>
>>> Is there a way to determine the UTC offset in time zone A when a
>>> program is running in time zone B? This must include adjustment
>>> for daylight/standard time.
>>
>> For that, look at the Get/SetTimeZoneInformation APIs. The TZI
>> structure contains the friendly names for a time zone, if any (both
>> Standard and Daylight) as well as the Daylight start/end dates and
>> offsets.
>>
>> This doesn't tell you anything about "New York" or "Tokyo" as such,
>> but with a little digging you can usually figure it out.
>
> Can you? GTZI/STZI only work with the current TZ, no? I've never
> found a way other
> than registry spelunking, and that's pretty dodgy too as you're
> betting that 1) MSFT
> is keeping up with stuff and 2) user is patching.

Hmmm... aside from forcing a temporary system change to a different
TZ, I guess you're right. I've not been daunted by registry hunts in
the past, so given a stable user base I guess I wouldn't mind doing
that here.

But maybe not for shrinkwrap software or anything that would get into
the hands of 'ordinary' users.

--
Jim

Howard Kaikow · Joined: 04 Oct 2007 Posts: 468

"Karl E. Peterson" wrote in message@TK2MSFTNGP03.phx.gbl...
> Jim Mack wrote:
> > Howard Kaikow wrote:
> >> When running a program on a computer in, say, Tokyo, I can get the
> >> UTC times that correspond to the Tokyo times.
> >>
> >> However, the program also needs to know the corresponding UTC Time
> >> for New York.
> >
> > UTC is the same in NY as it is in Tokyo. That's the point of UTC --
> > it's a standard that doesn't vary across the globe.
>
> Smile

>
> >> Is there a way to determine the UTC offset in time zone A when a
> >> program is running in time zone B? This must include adjustment for
> >> daylight/standard time.
> >
> > For that, look at the Get/SetTimeZoneInformation APIs. The TZI
> > structure contains the friendly names for a time zone, if any (both
> > Standard and Daylight) as well as the Daylight start/end dates and
> > offsets.
> >
> > This doesn't tell you anything about "New York" or "Tokyo" as such,
> > but with a little digging you can usually figure it out.
>
> Can you? GTZI/STZI only work with the current TZ, no? I've never found a
way other
> than registry spelunking, and that's pretty dodgy too as you're betting
that 1) MSFT
> is keeping up with stuff and 2) user is patching.

Ayup, that was my feeling.

I guess that I'll just hard code the rules for NY in the program and
calculate the values on the fly.

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Jim Mack wrote:
> Karl E. Peterson wrote:
>> Jim Mack wrote:
>>> Howard Kaikow wrote:
>>>
>>>> Is there a way to determine the UTC offset in time zone A when a
>>>> program is running in time zone B? This must include adjustment
>>>> for daylight/standard time.
>>>
>>> For that, look at the Get/SetTimeZoneInformation APIs. The TZI
>>> structure contains the friendly names for a time zone, if any (both
>>> Standard and Daylight) as well as the Daylight start/end dates and
>>> offsets.
>>>
>>> This doesn't tell you anything about "New York" or "Tokyo" as such,
>>> but with a little digging you can usually figure it out.
>>
>> Can you? GTZI/STZI only work with the current TZ, no? I've never found a way
>> other
>> than registry spelunking, and that's pretty dodgy too as you're betting that 1)
>> MSFT
>> is keeping up with stuff and 2) user is patching.
>
> Hmmm... aside from forcing a temporary system change to a different
> TZ, I guess you're right. I've not been daunted by registry hunts in
> the past, so given a stable user base I guess I wouldn't mind doing
> that here.

I think getting it out of the registry is doable, for sure. Just messy. IIRC, it's
a (undoc'd) binary structure?
--
..NET: It's About Trust!
http://vfred.mvps.org

Thorsten Albers · Joined: 04 Oct 2007 Posts: 756

Karl E. Peterson schrieb im Beitrag
...
> I've never found a way other
> than registry spelunking, and that's pretty dodgy too as you're betting
that 1) MSFT
> is keeping up with stuff and 2) user is patching.

Eh? And what is with SystemTimeToTzSpecificLocalTime()?

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------

Howard Kaikow · Joined: 04 Oct 2007 Posts: 468

What about SystemTimeToTzSpecificLocalTime?
Needs more investigation.

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Thorsten Albers wrote:
> Karl E. Peterson schrieb ...
>> I've never found a way other
>> than registry spelunking, and that's pretty dodgy too as you're betting that 1)
>> MSFT is keeping up with stuff and 2) user is patching.
>
> Eh? And what is with SystemTimeToTzSpecificLocalTime()?

A classic Catch-22? I guess it comes down to what elements of the TZI structure
need to be filled, in order for this call to succeed. Only way I know to reliably
fill in a TZI structure is with the calls previously discussed that only work with
the current TZ. I suppose it'd be worth playing with, though! It certainly *seems*
to be well-intentioned.
--
..NET: It's About Trust!
http://vfred.mvps.org

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Howard Kaikow wrote:
> What about SystemTimeToTzSpecificLocalTime?
> Needs more investigation.

I just revisited this. You're just as well off with DateAdd. That's all this
function really does -- just add a specified number of minutes to the specified UTC
time. Another way to do this would be:

Call GetTimeZoneInformation(TZI)
UTC = DateAdd("n", TZI.Bias, Now)
EST = DateAdd("n", 300, UTC)

But that doesn't begin to account for DST. For that, you're back to registry
spelunking, and the assumption the user has kept this system patched.
--
..NET: It's About Trust!
http://vfred.mvps.org

Thorsten Albers · Joined: 04 Oct 2007 Posts: 756

Karl E. Peterson schrieb im Beitrag
...
> A classic Catch-22? I guess it comes down to what elements of the TZI
structure
> need to be filled, in order for this call to succeed. Only way I know to
reliably
> fill in a TZI structure is with the calls previously discussed that only
work with
> the current TZ. I suppose it'd be worth playing with, though! It
certainly *seems*
> to be well-intentioned.

You are right! I have never used this function nor read its
documentation... Smile

But there is an MS KB article which should be of help
in filling the TZI structure (as you said, from the registry):
Q115231: Retrieving Time-Zone Information.

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Thorsten Albers wrote:
> Karl E. Peterson schrieb...
>> A classic Catch-22? I guess it comes down to what elements of the TZI structure
>> need to be filled, in order for this call to succeed. Only way I know to
>> reliably fill in a TZI structure is with the calls previously discussed that
>> only work with the current TZ. I suppose it'd be worth playing with, though!
>> It certainly *seems* to be well-intentioned.
>
> You are right! I have never used this function nor read its
> documentation... Smile

But there is an MS KB article which should be of help
> in filling the TZI structure (as you said, from the registry):
> Q115231: Retrieving Time-Zone Information.

Yeah, Randy's got one with code, on his site:

http://vbnet.mvps.org/index.html?code/locale/timezonedisplay.htm

At least my recollection about the structure being undoc'd was incorrect. Found an
interesting new feature, too. There's now a "Dynamic DST" subkey under some zones.
It appears they can be used to fine-tune DST bias in specific years. What's
interesting is, API support is only available on Vista and 2008, but the keys exist
on XP?!

Btw, it turns out the only element of the TZI that needs to be filled in is the
Bias. So really, it is just a very-messy DateAdd call.
--
..NET: It's About Trust!
http://vfred.mvps.org

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Jim Mack wrote:
> Hmmm... aside from forcing a temporary system change to a different
> TZ, I guess you're right. I've not been daunted by registry hunts in
> the past, so given a stable user base I guess I wouldn't mind doing
> that here.
>
> But maybe not for shrinkwrap software or anything that would get into
> the hands of 'ordinary' users.

The full horror just re-occurred to me. Are the TZ names found here:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones

localized? I would certainly suspect so. And if so, there's just no possible way
to count on being able to enumerate them looking for any specific name, is there?

If anyone running a non-English version of Windows would care to look, I'd be very
appreciative!
--
..NET: It's About Trust!
http://vfred.mvps.org

Karl E. Peterson · Joined: 04 Oct 2007 Posts: 4836

Karl E. Peterson wrote:
> Jim Mack wrote:
>> Hmmm... aside from forcing a temporary system change to a different
>> TZ, I guess you're right. I've not been daunted by registry hunts in
>> the past, so given a stable user base I guess I wouldn't mind doing
>> that here.
>>
>> But maybe not for shrinkwrap software or anything that would get into
>> the hands of 'ordinary' users.
>
> The full horror just re-occurred to me. Are the TZ names found here:
>
> HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones
>
> localized? I would certainly suspect so. And if so, there's just no possible way
> to count on being able to enumerate them looking for any specific name, is there?
>
> If anyone running a non-English version of Windows would care to look, I'd be very
> appreciative!

Specifically, whether these subkey [display] names are the same:

Afghanistan Standard Time [(GMT+04:30) Kabul]
Alaskan Standard Time [(GMT-09:00) Alaska]
Arab Standard Time [(GMT+03:00) Kuwait, Riyadh]
Arabian Standard Time [(GMT+04:00) Abu Dhabi, Muscat]
Arabic Standard Time [(GMT+03:00) Baghdad]
Atlantic Standard Time [(GMT-04:00) Atlantic Time (Canada)]
AUS Central Standard Time [(GMT+09:30) Darwin]
AUS Eastern Standard Time [(GMT+10:00) Canberra, Melbourne, Sydney]
Azerbaijan Standard Time [(GMT+04:00) Baku]
Azores Standard Time [(GMT-01:00) Azores]
Canada Central Standard Time [(GMT-06:00) Saskatchewan]
Cape Verde Standard Time [(GMT-01:00) Cape Verde Is.]
Caucasus Standard Time [(GMT+04:00) Yerevan]
Cen. Australia Standard Time [(GMT+09:30) Adelaide]
Central America Standard Time [(GMT-06:00) Central America]
Central Asia Standard Time [(GMT+06:00) Astana, Dhaka]
Central Brazilian Standard Time [(GMT-04:00) Manaus]
Central Europe Standard Time [(GMT+01:00) Belgrade, Bratislava, Budapest,
Ljubljana, Prague]
Central European Standard Time [(GMT+01:00) Sarajevo, Skopje, Warsaw, Zagreb]
Central Pacific Standard Time [(GMT+11:00) Magadan, Solomon Is., New
Caledonia]
Central Standard Time [(GMT-06:00) Central Time (US & Canada)]
Central Standard Time (Mexico) [(GMT-06:00) Guadalajara, Mexico City,
Monterrey - New]
China Standard Time [(GMT+08:00) Beijing, Chongqing, Hong Kong,
Urumqi]
Dateline Standard Time [(GMT-12:00) International Date Line West]
E. Africa Standard Time [(GMT+03:00) Nairobi]
E. Australia Standard Time [(GMT+10:00) Brisbane]
E. Europe Standard Time [(GMT+02:00) Minsk]
E. South America Standard Time [(GMT-03:00) Brasilia]
Eastern Standard Time [(GMT-05:00) Eastern Time (US & Canada)]
Egypt Standard Time [(GMT+02:00) Cairo]
Ekaterinburg Standard Time [(GMT+05:00) Ekaterinburg]
Fiji Standard Time [(GMT+12:00) Fiji, Kamchatka, Marshall Is.]
FLE Standard Time [(GMT+02:00) Helsinki, Kyiv, Riga, Sofia,
Tallinn, Vilnius]
Georgian Standard Time [(GMT+03:00) Tbilisi]
GMT Standard Time [(GMT) Greenwich Mean Time : Dublin,
Edinburgh, Lisbon, London]
Greenland Standard Time [(GMT-03:00) Greenland]
Greenwich Standard Time [(GMT) Casablanca, Monrovia, Reykjavik]
GTB Standard Time [(GMT+02:00) Athens, Bucharest, Istanbul]
Hawaiian Standard Time [(GMT-10:00) Hawaii]
India Standard Time [(GMT+05:30) Chennai, Kolkata, Mumbai, New
Delhi]
Iran Standard Time [(GMT+03:30) Tehran]
Israel Standard Time [(GMT+02:00) Jerusalem]
Jordan Standard Time [(GMT+02:00) Amman]
Korea Standard Time [(GMT+09:00) Seoul]
Mexico Standard Time [(GMT-06:00) Guadalajara, Mexico City,
Monterrey - Old]
Mexico Standard Time 2 [(GMT-07:00) Chihuahua, La Paz, Mazatlan -
Old]
Mid-Atlantic Standard Time [(GMT-02:00) Mid-Atlantic]
Middle East Standard Time [(GMT+02:00) Beirut]
Montevideo Standard Time [(GMT-03:00) Montevideo]
Mountain Standard Time [(GMT-07:00) Mountain Time (US & Canada)]
Mountain Standard Time (Mexico) [(GMT-07:00) Chihuahua, La Paz, Mazatlan -
New]
Myanmar Standard Time [(GMT+06:30) Yangon (Rangoon)]
N. Central Asia Standard Time [(GMT+06:00) Almaty, Novosibirsk]
Namibia Standard Time [(GMT+02:00) Windhoek]
Nepal Standard Time [(GMT+05:45) Kathmandu]
New Zealand Standard Time [(GMT+12:00) Auckland, Wellington]
Newfoundland Standard Time [(GMT-03:30) Newfoundland]
North Asia East Standard Time [(GMT+08:00) Irkutsk, Ulaan Bataar]
North Asia Standard Time [(GMT+07:00) Krasnoyarsk]
Pacific SA Standard Time [(GMT-04:00) Santiago]
Pacific Standard Time [(GMT-08:00) Pacific Time (US & Canada)]
Pacific Standard Time (Mexico) [(GMT-08:00) Tijuana, Baja California]
Romance Standard Time [(GMT+01:00) Brussels, Copenhagen, Madrid,
Paris]
Russian Standard Time [(GMT+03:00) Moscow, St. Petersburg,
Volgograd]
SA Eastern Standard Time [(GMT-03:00) Buenos Aires, Georgetown]
SA Pacific Standard Time [(GMT-05:00) Bogota, Lima, Quito, Rio Branco]
SA Western Standard Time [(GMT-04:00) Caracas, La Paz]
Samoa Standard Time [(GMT-11:00) Midway Island, Samoa]
SE Asia Standard Time [(GMT+07:00) Bangkok, Hanoi, Jakarta]
Singapore Standard Time [(GMT+08:00) Kuala Lumpur, Singapore]
South Africa Standard Time [(GMT+02:00) Harare, Pretoria]
Sri Lanka Standard Time [(GMT+05:30) Sri Jayawardenepura]
Taipei Standard Time [(GMT+08:00) Taipei]
Tasmania Standard Time [(GMT+10:00) Hobart]
Tokyo Standard Time [(GMT+09:00) Osaka, Sapporo, Tokyo]
Tonga Standard Time [(GMT+13:00) Nuku'alofa]
US Eastern Standard Time [(GMT-05:00) Indiana (East)]
US Mountain Standard Time [(GMT-07:00) Arizona]
Vladivostok Standard Time [(GMT+10:00) Vladivostok]
W. Australia Standard Time [(GMT+08:00) Perth]
W. Central Africa Standard Time [(GMT+01:00) West Central Africa]
W. Europe Standard Time [(GMT+01:00) Amsterdam, Berlin, Bern, Rome,
Stockholm, Vienna]
West Asia Standard Time [(GMT+05:00) Islamabad, Karachi, Tashkent]
West Pacific Standard Time [(GMT+10:00) Guam, Port Moresby]
Yakutsk Standard Time [(GMT+09:00) Yakutsk]

Thanks... Karl
--
..NET: It's About Trust!
http://vfred.mvps.org

Thorsten Albers · Joined: 04 Oct 2007 Posts: 756

Karl E. Peterson schrieb im Beitrag
...
> Specifically, whether these subkey [display] names are the same:
>
> Afghanistan Standard Time [(GMT+04:30) Kabul]
> Alaskan Standard Time [(GMT-09:00) Alaska]
> Arab Standard Time [(GMT+03:00) Kuwait, Riyadh]
....
> West Asia Standard Time [(GMT+05:00) Islamabad, Karachi,
Tashkent]
> West Pacific Standard Time [(GMT+10:00) Guam, Port Moresby]
> Yakutsk Standard Time [(GMT+09:00) Yakutsk]

On Windows 98 SE (HKLM\...\Windows\CurrentVersion\TimeZones) the entries
look like this:
\TimeZones\Afghanistan\
Display (GMT+04:30) Kabul
Dlt Afghanistan Sommerzeit
MapID -1,73
Std Afghanistan Normalzeit
TZI ...
....
\TimeZones\West Asia\
Display (GMT+05:00) Islamabad, Karatschi, Taschkent
Dlt Westasien Sommerzeit
MapID 10,11
Std Westasien Normalzeit
TZI ...
....

i.e. the keys are not localized but are different from the ones you have
listed (in that they don't have the addition ' Standard Time'. The subkeys
'Display', 'Dlt', and 'Std' obviously are localized.

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------

Get Current Time Bias from numbered CDO Time Zone? Can anyone think of a way that I can get the current Time Bias, taking into account any Daylight saving time currently in force, if the Time Zone is specified as a number from this table?

API for Time Zone/Region I am working with Ms-Access VBA (2003). How can I identify the used by the PC? Or, how can I convert the PC's time [i.e: now()] to Greenwich Mean Time (GMT)? Thank you, Tom.

Time Zone Information First, has Windows 2000 been updated to reflect the changed spec for when we switch to Daylight time is the USA next March? And what about such changes in other regions? If this hardcoded into Win 2000, we are stuck. Second, the crit

Time Zone Abbreviation I need to display a date/time including an abbreviation for the time zone, e.g. EST, PDT. I used code bastardized from some samples I found on the Internet, but even when I explicitly request I get "Eastern Standard Time". (FYI - I am in

program runs inside VB IDE, crash when run the generated exe sorry if this is not the right forum for this subject My VB program use some array, when I run it inside the IDE, it is ok, but when I gen exe and run, it crash, and says : "Run time error '10' this array is fixed or temporarily locked " any one know the