 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Win API / February 2008UTC offset for MY when program runs in another time zone
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. > 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.  SignatureJim Mack MicroDexterity Inc www.microdexterity.com >> When running a program on a computer in, say, Tokyo, I can get the >> UTC times that correspond to the Tokyo times. [quoted text clipped - 4 lines] > 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 [quoted text clipped - 7 lines] > 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. Signature.NET: It's About Trust! http://vfred.mvps.org >>> 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 [quoted text clipped - 13 lines] > 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. SignatureJim >>>> 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 [quoted text clipped - 18 lines] > 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? Signature.NET: It's About Trust! http://vfred.mvps.org What about SystemTimeToTzSpecificLocalTime? Needs more investigation. > 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. Signature.NET: It's About Trust! http://vfred.mvps.org > 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 [quoted text clipped - 3 lines] > 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! Signature.NET: It's About Trust! http://vfred.mvps.org >> 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 [quoted text clipped - 13 lines] > 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 Signature.NET: It's About Trust! http://vfred.mvps.org Karl E. Peterson <karl@mvps.org> schrieb im Beitrag <uwP2ow5ZIHA.2000@TK2MSFTNGP05.phx.gbl>... > 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 ... <binary data> ... \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. Signature---------------------------------------------------------------------- THORSTEN ALBERS Universität Freiburg albers@ uni-freiburg.de ---------------------------------------------------------------------- > Karl E. Peterson <karl@mvps.org> schrieb im Beitrag > <uwP2ow5ZIHA.2000@TK2MSFTNGP05.phx.gbl>... [quoted text clipped - 28 lines] > listed (in that they don't have the addition ' Standard Time'. The subkeys > 'Display', 'Dlt', and 'Std' obviously are localized. What a mess! That really prevents you from, in any way, programmatically extracting a specific TZ from any given Windows install. Hmmmm, unless maybe you could go off the MapID or Index? (Though, it appears that on 9x, there isn't an Index entry under each subkey?) Thanks... Signature.NET: It's About Trust! http://vfred.mvps.org Karl E. Peterson <karl@mvps.org> schrieb im Beitrag <#oQW87CaIHA.2000@TK2MSFTNGP05.phx.gbl>... > What a mess! That really prevents you from, in any way, programmatically extracting > a specific TZ from any given Windows install. Hmmmm, unless maybe you could go off > the MapID or Index? (Though, it appears that on 9x, there isn't an Index entry > under each subkey?) I have done a short google search on "+time +zone +mapid" and found an interesting statement from SUN for their Java DK from 03/03/2006: "The platform time zone detection code needs to be updated to support Windows Vista. ... The time zones registry no longer has 'mapID' on which the time zone detection code relies". Other interesting sites are listed as well. Obviously most people rely on the MapID... Signature---------------------------------------------------------------------- THORSTEN ALBERS Universität Freiburg albers@ uni-freiburg.de ---------------------------------------------------------------------- > Karl E. Peterson <karl@mvps.org> schrieb ... >> What a mess! That really prevents you from, in any way, programmatically [quoted text clipped - 9 lines] > Other interesting sites are listed as well. Obviously most people rely on > the MapID... Man, I'm sure glad I didn't "discover" that just before Vista shipped! What a drag... I guess the only good news that search turns up, is that the registry is at best only ~75% accurate anyway, so it's not much of a solution in the first place. Signature.NET: It's About Trust! http://vfred.mvps.org > >> When running a program on a computer in, say, Tokyo, I can get the > >> UTC times that correspond to the Tokyo times. [quoted text clipped - 22 lines] > 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 <karl@mvps.org> schrieb im Beitrag <eLUkc02ZIHA.4880@TK2MSFTNGP03.phx.gbl>... > 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()? Signature---------------------------------------------------------------------- THORSTEN ALBERS Universität Freiburg albers@ uni-freiburg.de ---------------------------------------------------------------------- > Karl E. Peterson <karl@mvps.org> 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. <g> Signature.NET: It's About Trust! http://vfred.mvps.org Karl E. Peterson <karl@mvps.org> schrieb im Beitrag <uNkGMD4ZIHA.2000@TK2MSFTNGP05.phx.gbl>... > 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. <g> You are right! I have never used this function nor read its documentation... :-) 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. Signature---------------------------------------------------------------------- THORSTEN ALBERS Universität Freiburg albers@ uni-freiburg.de ---------------------------------------------------------------------- > Karl E. Peterson <karl@mvps.org> schrieb... >> A classic Catch-22? I guess it comes down to what elements of the TZI structure [quoted text clipped - 7 lines] > 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. Signature.NET: It's About Trust! http://vfred.mvps.org http://vbnet.mvps.org/index.html?code/locale/timezonedisplay.htm The above is an example from Randy Birch that enumerates time zone info from the registry. I have modified the example to display the DaylightDate and StandardDate. In order to do this, I set wYear = Year(NOW) and used two algorithms to produce a string representation of each date. There were 74 time zones listed. 36 of the time zones displayed, apparently, plausible dates for 2008. 38, as I recall, of the time zones were way off. I used two algorithms to convert the SystemTimes to a string, in both cases setting te year to 2008. With one algorithm, the bad results were always 30 December 1899 0:00. With the other algorithm, 1/1/1601. So, there are two issues: A. Is the info in the registry correct for the time zones for which odd values were reported? B. Are the algorithms I (ab)used correct? One case used the following code: Private Function STtoFT(st As SYSTEMTIME) As FILETIME Dim ft As FILETIME SystemTimeToFileTime st, ft LocalFileTimeToFileTime ft, ft STtoFT = ft End Function Private Function FTtoString(ByRef originalFT As FILETIME, Optional blnIncludeMilliseconds = False) As String Dim dat As Date Dim ft As FILETIME Dim st As SYSTEMTIME FileTimeToLocalFileTime originalFT, ft FileTimeToSystemTime ft, st With st If blnIncludeMilliseconds Then dat = DateSerial(.wYear, .wMonth, .wDay) + _ TimeSerial(.wHour, .wMinute, .wSecond) + CDbl(.wMilliseconds / DayMilliseconds) Else dat = DateSerial(.wYear, .wMonth, .wDay) + _ TimeSerial(.wHour, .wMinute, .wSecond) End If End With FTtoString = FormatDateTime(dat, vbGeneralDate) End Function The other case used the following code: Private Function GetTimeZoneDate(tziDate As SYSTEMTIME, ByVal lYear As Long) As Date Dim dat As Date With tziDate Select Case .wDay 'week in month Case 1 To 4 dat = DateSerial(lYear, .wMonth, _ (.wDayOfWeek - (Weekday(DateSerial(lYear, .wMonth, 1)) - 1) _ + .wDay * 7) Mod 7 + 1) Case 5 dat = DateSerial(lYear, .wMonth + 1, 1) dat = DateAdd("d", dat, _ -(Weekday(dat) - .wDayOfWeek + 7) Mod 7) End Select End With GetTimeZoneDate = dat End Function Private Function GetTimeZoneTime(tzi As SYSTEMTIME) As Date GetTimeZoneTime = TimeSerial(tzi.wHour, tzi.wMinute, tzi.wSecond) End Function Good chance the problem is caused by bad registry values. For example: (GMT+12:00) Fiji, Kamchatka, Marshall Is.Fiji Standard TimeFiji Daylight Time-720-780Saturday, 30 December 1899 at 00:00:00Saturday, 30 December 1899 at 00:00:00 (GMT+12:00) Auckland, WellingtonNew Zealand Standard TimeNew Zealand Daylight Time-720-780Sunday, 02 March 2008 at 02:00:00Sunday, 05 October 2008 at 02:00:00 Both time zones are GMT+12:00, with an offset of -720, yet the date values returned are crazy for Fiji and the ones for Auckland are plausible. The TZI value for Fiji is different. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Fiji Standard Time] "Display"="(GMT+12:00) Fiji, Kamchatka, Marshall Is." "Dlt"="Fiji Daylight Time" "Std"="Fiji Standard Time" "MapID"="24,25" "Index"=dword:0000011d "TZI"=hex:30,fd,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,00,00,00,00,00,00,00,00, 00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\New Zealand Standard Time] "Display"="(GMT+12:00) Auckland, Wellington" "Dlt"="New Zealand Daylight Time" "Std"="New Zealand Standard Time" "MapID"="78,79" "Index"=dword:00000122 "TZI"=hex:30,fd,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,03,00,00,00,03,00,02,00, 00,\ 00,00,00,00,00,00,00,0a,00,00,00,01,00,02,00,00,00,00,00,00,00 Can we agree that such values are corrupted? Ayup, registry values are nonsense. For Fiji, .wYear is 2008, as I set it, but .wMonth, .wDay, .wHour and .wMinute are 0. Select Case sResults(1) Case "Fiji Standard Time" Debug.Print With stStandardDate Debug.Print "Fiji Standard", .wYear, .wMonth, .wDay, .wHour, .wMinute End With With stDaylightDate Debug.Print "Fiji Daylight", .wYear, .wMonth, .wDay, .wHour, .wMinute End With Case "New Zealand Standard Time" Debug.Print With stStandardDate Debug.Print "New Zealand Standard", .wYear, .wMonth, .wDay, .wHour, .wMinute End With With stDaylightDate Debug.Print "New Zealand Daylight", .wYear, .wMonth, .wDay, .wHour, .wMinute End With End Select For the purposes of theproblem I originally posted to start this thread,a ll I need are correct values for the local system on which the program is running (I sure hope those are right on the local system), and, hopefully, valid values for New York (Eastern Standard/Daylight Time., Howard Kaikow <kaikow@standards.com> schrieb im Beitrag <OXaC8SDbIHA.1212@TK2MSFTNGP05.phx.gbl>... > For the purposes of theproblem I originally posted to start this thread,a ll > I need are correct values for the local system on which the program is > running (I sure hope those are right on the local system), and, hopefully, > valid values for New York (Eastern Standard/Daylight Time., To sum it up: Don't rely on the registry. Instead hardcode the time zones in a DLL of your own and distribute this DLL with you applications. An additional note: At least Windows 95 and 98 (SE) were shipped with a tool called 'tzedit.exe' which allowed any modifications of the time zone data in the registry (presumably it is available somewhere on the NT etc. CDs as well). This shows how reliable the time zone data in the registry is... Signature---------------------------------------------------------------------- THORSTEN ALBERS Universität Freiburg albers@ uni-freiburg.de ---------------------------------------------------------------------- > To sum it up: Don't rely on the registry. Instead hardcode the time zones > in a DLL of your own and distribute this DLL with you applications. Earlier in this thread, I had suggested that as a solution. I'll just have to remain alert as to when the rules for Eastern Daylight changes. I just need to have the UTC for a specific Eastern time, same every day. I need to know whether local files were created after that threshhold time. I may put in a spin control to let the user pick that threshhold, in case the rules change. > An additional note: At least Windows 95 and 98 (SE) were shipped with a > tool called 'tzedit.exe' which allowed any modifications of the time zone > data in the registry (presumably it is available somewhere on the NT etc. > CDs as well). This shows how reliable the time zone data in the registry > is... tzedit does no help when my program is running on another's computer. I'm not going to fool with their time zone values. It would seem (to me) to be a very simple task for MSFT to provide a means to update the time zone info in the registry, at least for Windows 2000 and later. Also, I just realized how careful one must be using DateSerial, as it uses abolute, as well as relative adjustments. Option Explicit Private Sub Form_Load() Dim bDate As Boolean Dim dat As Date Me.AutoRedraw = True bDate = TestDateSerial(2008, 0, 0, dat) ' Returns 11/30/2007 bDate = TestDateSerial(2008, 1, 0, dat) ' Returns 12/31/2007 bDate = TestDateSerial(2008, 0, 1, dat) ' Returns 12/1/2007 bDate = TestDateSerial(2008, 1, 1, dat) ' Valid: Returns 1/1/2008 bDate = TestDateSerial(0, 0, 0, dat) ' Returns 11/30/1999 bDate = TestDateSerial(0, 1, 0, dat) ' Returns 12/31/1999 bDate = TestDateSerial(0, 0, 1, dat) ' Returns 12/1/1999 bDate = TestDateSerial(0, 1, 1, dat) ' Valid: Returns 1/1/2000 End Sub Public Function TestDateSerial(lYear As Long, lMonth As Long, lDay As Long, dat As Date) As Boolean Dim sDate As String dat = DateSerial(lYear, lMonth, lDay) ' Uses USA format sDate = CStr(lMonth) & "/" & CStr(lDay) & "/" & CStr(lYear) If IsDate(sDate) Then Me.Print "Valid: " & CDate(sDate) TestDateSerial = True Else Me.Print "Not valid: " & sDate TestDateSerial = False End If End Function > Can we agree that such values are corrupted? I didn't dig through it but if the wMonth value is zero then there is no DST time for that time zone so the other values could be garbage. > > Can we agree that such values are corrupted? > > I didn't dig through it but if the wMonth value is zero then there is no DST > time for that time zone so the other values could be garbage. Ah, thanx! > Good chance the problem is caused by bad registry values. > > For example: > (GMT+12:00) Fiji, Kamchatka, Marshall Is.Fiji Standard TimeFiji Daylight > Time-720-780Saturday, 30 December 1899 at 00:00:00Saturday, 30 December 1899 > at 00:00:00 ?format$(0, "long date"), format$(0, "long time") Saturday, December 30, 1899 12:00:00 AM That's a date to commit to memory. :-) Signature.NET: It's About Trust! http://vfred.mvps.org Using SystemTimeToTzSpecificLocalTime almost gets me there. But I have not yet found a way to determine when the TZI.BIAS for NY should be 240 instead of 300. I can brute force this by vetting the rules: Daylight time starts on the 2nd Sunday of March at 02:00 Daylight time ends the first Sunday of November at 02:00. During the above period, the BIAS would be 240, otherwise, 300. > Using SystemTimeToTzSpecificLocalTime almost gets me there. > [quoted text clipped - 6 lines] > > During the above period, the BIAS would be 240, otherwise, 300. Exactly the dillema, yep. And if the dates change again in the future, you're hosed that way too. To reiterate, DateAdd will work just fine, because you can easily get UTC with that and your own BIAS. Signature.NET: It's About Trust! http://vfred.mvps.org >> Using SystemTimeToTzSpecificLocalTime almost gets me there. >> [quoted text clipped - 14 lines] > get UTC with that > and your own BIAS. I've got the solution. Just have the distant office send you an email every Monday, and extract the offset from the headers... SignatureJim in <O1hIFPDaIHA.3400@TK2MSFTNGP03.phx.gbl> >I've got the solution. Just have the distant office send you an email >every Monday, and extract the offset from the headers... That's not so far fetched. It would also be easy if you had a web server in that specific zone. --- Stefan Berglund >>> Using SystemTimeToTzSpecificLocalTime almost gets me there. >>> [quoted text clipped - 17 lines] > I've got the solution. Just have the distant office send you an email > every Monday, and extract the offset from the headers... Hopefully, it's not coming from some goob's laptop! Signature.NET: It's About Trust! http://vfred.mvps.org The specifics of my problem are: 1. User is running the program in time zone X. 2. Relevant files are opened, and for each, the UTC time is determined using the usual APIs. 3. Each of those times has to be compared to a predetermined time in NY, I was thinking that this was easiest done if the specific NY time was also in UTC. Alas, the only way seems for me to determine whether BIAS should be 240 or 300 appears to be by using the rules below to get the UTC for the specific time: Daylight time starts on the 2nd Sunday of March at 02:00 Daylight time ends the first Sunday of November at 02:00. During the above period, the BIAS would be 240, otherwise, 300. Of course, if the rules change ...! The program hasto run in windoze 2000, so APIs added in XP or Vista could not be used, > The specifics of my problem are: > [quoted text clipped - 6 lines] > in NY, I was thinking that this was easiest done if the specific NY > time was also in UTC. If you can reduce the problem domain to this, that you need to know the current offset fron UTC in NYC, or you need to know if NYC is currently on Daylight time, then it like seems my solution, as modified by Stefan, is not so farfetched. There is _certainly_ some web site in NYC that when loaded will give you the current time -- maybe one of the webcams in Times Square. A simple comparison to local time gives you your information. If you need to know this for files dated in the past, you can keep a small database where you store the results of performing this query every Monday morning. SignatureJim > > 3. Each of those times has to be compared to a predetermined time > > in NY, I was thinking that this was easiest done if the specific NY > > time was also in UTC. The time is not the current time in NY, rather it is a set time that same day. For example, my prog needs to know whether files on the local system were created after a predetermined NY time that same day. I guess I'll wait until 9 March 2008 and see what UTC is returned for NY with tz.Bias = 300 tz.DaylightBias = -60 >>> 3. Each of those times has to be compared to a predetermined time >>> in NY, I was thinking that this was easiest done if the specific [quoted text clipped - 6 lines] > system were created after > a predetermined NY time that same day. How does that differ in principle from the scenario I suggested? Just offset by the difference in current times, which cannot change arbitrarily, but only at certain points in the year. Those will always be on a Sunday -- if you get the NY time at a point after what you believe is 03:00 Sunday NY time, the result will be consistent for 7 days. C'mon, man, think outside the clock. (-: SignatureJim Is registry wrong? Windows 2000 registry indicates that Indiana has not adopted Daylight time, however, http://aa.usno.navy.mil/faq/docs/daylight_time.php says "Indiana adopted its use beginning in 2006".. > Is registry wrong? > > Windows 2000 registry indicates that Indiana has not adopted Daylight > time, > however, http://aa.usno.navy.mil/faq/docs/daylight_time.php says "Indiana > adopted its use beginning in 2006".. http://www.microsoft.com/windows/timezone.mspx > http://www.microsoft.com/windows/timezone.mspx Thanx, but I'm using Windows 2000. >> http://www.microsoft.com/windows/timezone.mspx > > Thanx, but I'm using Windows 2000. MS provided no patches or anything for Windows 2000 so any registry changes needed for all the timezones had to be done manually or via a third-party fix. If you're running Win2K and never updated things as the DST and other time zone info changed then what you have is definitely out of date. > MS provided no patches or anything for Windows 2000 so any registry changes > needed for all the timezones had to be done manually or via a third-party > fix. If you're running Win2K and never updated things as the DST and other > time zone info changed then what you have is definitely out of date. The only updates I would have would be those applied by Windows update and the Eastern Standard/Daylight Time changes for 2007. Is there a /reg file that incorporates the latest changes? http://support.microsoft.com/kb/914387 describes how to make the changes. Also, see http://blogs.technet.com/dst2007/archive/2007/03/07/is-the-dst-update-purchased- through-extended-hotfix-support-needed-for-windows-2000.aspx/ "Is the DST Update purchased through extended hotfix support needed for Windows 2000? Q: Is the DST Update purchased through extended hotfix support needed for Windows 2000? Tech support keeps telling me I can do it manually, but how? A: For Windows 2000, you can use KB914387 to manually patch your Windows 2000 OS. See http://support.microsoft.com/kb/930688, “Support WebCast: Deploying Microsoft Windows 2000 updates for daylight saving time changes for worldwide use” Filed under: Windows Operating System" I guess I need to create a .reg file from http://support.microsoft.com/kb/9155560, then apply the techniques http://support.microsoft.com/kb/914387. P.S. The KB articles that describe using tzedit.exe state "The Time Zone Editor does not provide the capabilities to add the Dynamic DSTregistry subkeys". Just what are the Dynamic DSTregistry subkeys. Ignore previous message, corrected message below. > > MS provided no patches or anything for Windows 2000 so any registry > changes [quoted text clipped - 10 lines] > > Also, see http://blogs.technet.com/dst2007/archive/2007/03/07/is-the-dst-update-purchased- through-extended-hotfix-support-needed-for-windows-2000.aspx/ > "Is the DST Update purchased through extended hotfix support needed for > Windows 2000? [quoted text clipped - 15 lines] > > Just what are the Dynamic DSTregistry subkeys. >> P.S. >> The KB articles that describe using tzedit.exe state "The Time Zone [quoted text clipped - 3 lines] >> >> Just what are the Dynamic DSTregistry subkeys. things like this: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Mountain Standard Time\Dynamic DST] "FirstEntry"=dword:000007d6 "LastEntry"=dword:000007d7 "2006"=hex:a4,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,02,00,\ 00,00,00,00,00,00,00,00,04,00,00,00,01,00,02,00,00,00,00,00,00,00 "2007"=hex:a4,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,00,\ 00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00 Instead of a single structure you have different ones for each year > >> P.S. > >> The KB articles that describe using tzedit.exe state "The Time Zone [quoted text clipped - 10 lines] > "FirstEntry"=dword:000007d6 > "LastEntry"=dword:000007d7 "2006"=hex:a4,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,02,00 ,\ > 00,00,00,00,00,00,00,00,04,00,00,00,01,00,02,00,00,00,00,00,00,00 "2007"=hex:a4,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,00 ,\ > 00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00 > > Instead of a single structure you have different ones for each year I have no such critters in my Windows 2000 registry, Is this an XP and later thing? > I have no such critters in my Windows 2000 registry, > > Is this an XP and later thing? Yes, it came in with the updates described in the KB articles. > MS provided no patches or anything for Windows 2000 so any registry changes > needed for all the timezones had to be done manually or via a third-party > fix. If you're running Win2K and never updated things as the DST and other > time zone info changed then what you have is definitely out of date. KB article 91437 seems to update Windows 2000. Are StandardStart and DaylightStart in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation supposed to identical with the correspomding values in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time\TZI? '[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] '"Bias"=dword:0000012c '"StandardName"="Eastern Standard Time" '"StandardBias"=dword:00000000 '"StandardStart"=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00 '"DaylightName"="Eastern Daylight Time" '"DaylightBias"=dword:ffffffc4 '"DaylightStart"=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00 '"ActiveTimeBias"=dword:0000012c '[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time] '"Display"="(GMT-05:00) Eastern Time (US & Canada)" '"Dlt"="Eastern Daylight Time" '"Std"="Eastern Standard Time" '"MapID"="38,39" '"Index"=dword:00000023 '"TZI"=hex:2c,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02,00 ,00,\ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\Dayl ighhtStart has 00 00 03 00 02 00 02 00 00 00 00 00 00 00 00 00, which yields an incorrect date/time. Which differs from the value extracted from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time\TZI 00 00 03 00 00 00 02 00 02 00 00 00 00 00 00 00, which yields the correct dae/time. Similar mismatch occurs for StandardStart. > Are StandardStart and DaylightStart in > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation > supposed to identical with the correspomding values in > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time > Zones\Eastern Standard Time\TZI? The structures are different; I think it's just that one has Integer values while the other has Long values for some elements but it's been a while since I delved into it. The TZI values under the Time Zones section uses this: Private Type REG_TZI Bias As Long StandardBias As Long DaylightBias As Long StandardDate As SYSTEMTIME DaylightDate As SYSTEMTIME End Type For the values under CurrentControlSet I'd suggest always using the GetTimeZoneInformation and SetTimeZoneInformation API calls as they will do any necessary mappings to the structure there. > The structures are different; I think it's just that one has Integer values > while the other has Long values for some elements but it's been a while > since I delved into it. I'm just grabbing the REG_BINARY values from the TimeZoneInformation key. Each has 16 bytes, as do the corresponding critters in the TZI key. Why would the two values differ? > For the values under CurrentControlSet I'd suggest always using the > GetTimeZoneInformation and SetTimeZoneInformation API calls as they will do > any necessary mappings to the structure there. Yes, but the ActiveTimeBias key is not made directly available. As long as I was grabbing ActiveTimeBias, I figured that I'd grab everything else. Only StandardStart and DaylightStart differ from the values in the TZI key. At this time, I do not believe that I'll need to use ActiveTimeBias on the local computer, but I figured I'd grab all the values anyway. For the NY Time, I'll have to calculate the "ActiveTimeBias", hoping that the TZ Database info for Eastern Standard Time is correct.. I'll be distributing a program that allows the user to verify the settings for their local time zone and for Eastern Standard Time. >> The structures are different; I think it's just that one has Integer > values [quoted text clipped - 4 lines] > Each has 16 bytes, as do the corresponding critters in the TZI key. > Why would the two values differ? This is Microsoft. Why make it consistent when you can make it confusing? > For the NY Time, I'll have to calculate the "ActiveTimeBias", hoping that > the TZ Database info for Eastern Standard Time is correct.. > I'll be distributing a program that allows the user to verify the settings > for their local time zone and for Eastern Standard Time. I have a feeling I may be having to do something similar myself soon. We still have a ton of Win2K clients and the number of TZ changes is becoming unmanageable. > I have a feeling I may be having to do something similar myself soon. We > still have a ton of Win2K clients and the number of TZ changes is becoming > unmanageable. KB article 914387 addresses the case of Windows 2000. The instructions are not complete, but I managed to do the following: 1. I created a .reg file by COPYING the complete database in the article. 2. At the beginning of the file, I added a [-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones]. 3. I then copied the given vbs script into a VB6 project and ran the code within VB. 4. I then ran the Microsoft Office Outlook Tool Time Zone Data Update Tool for Microsoft Office Outlook referenced in KB 914387. I have a multiboot system with a different version of Office in each OS. One OS has Outlook 98, so the Outlook uodate tool won't work there. No problem running the above 4 steps on the OS with Office XP and Office 2003. However, on the OS with Office 2000, the installation of the Outllook tool failed with an error (posted to the Outlook.general newsgroup a few daze ago, no response thus far). |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.