Time Error

[Meanon]

Since the time change on Sunday my WinXP Pro computer shows the right
time in the Windows clock (in the system tray), but programs that use
a function call to get the time from the operating system are 1 hour
ahead. I recall something similar happened the last time the clocks
changed.

Does anyone know of a fix for this?

 

[Pegasus [MVP]]

Since the time change on Sunday my WinXP Pro computer shows the right
time in the Windows clock (in the system tray), but programs that use
a function call to get the time from the operating system are 1 hour
ahead. I recall something similar happened the last time the clocks
changed.

Does anyone know of a fix for this?

You need to post more details:
- Which programs?
- What function calls?
- Did you tick the box in the Time Zone display marked "Automatically adjust
clock for daylight saving changes"?
- When you open a Command Prompt, does the command
echo Time=%time%
show the correct time?

 

[Meanon]

You need to post more details:
- Which programs?
- What function calls?
- Did you tick the box in the Time Zone display marked "Automatically adjust
clock for daylight saving changes"?
- When you open a Command Prompt, does the command
   echo Time=%time%
   show the correct time?

Several of my webcam programs as well as a program the controls an
Outdoor LED Display Sign like the ones you see at malls, etc.

Not sure about the specific function call but the software vendor said
they use "a standard function call to get the current time from the
operating system". I assume this would be a function call made from a
C program to a standard system DLL. According to the vendor this is a
known OS bug.

Yes, the time is automatically adjusted by the OS and the proper time
is displayed in the System Tray clock.

When I open a command prompt and echo Time=%time% it displays the
correct time.

TIA.

 

[Pegasus [MVP]]

You need to post more details:
- Which programs?
- What function calls?
- Did you tick the box in the Time Zone display marked "Automatically
adjust
clock for daylight saving changes"?
- When you open a Command Prompt, does the command
echo Time=%time%
show the correct time?

Several of my webcam programs as well as a program the controls an
Outdoor LED Display Sign like the ones you see at malls, etc.

Not sure about the specific function call but the software vendor said
they use "a standard function call to get the current time from the
operating system". I assume this would be a function call made from a
C program to a standard system DLL. According to the vendor this is a
known OS bug.

Yes, the time is automatically adjusted by the OS and the proper time
is displayed in the System Tray clock.

When I open a command prompt and echo Time=%time% it displays the
correct time.

TIA.

==============

I've heard this line a few times before: "It's a known OS bug". This is
often the first line of defense by vendors. When pressed for substantiation
of "known", they invariably fail to deliver. If this was a known bug then it
would be widely known by know - Windows XP has been out for many years! I
recommend you run two more tests before leaning on your vendor. Both tests
obtain the OS's system time.

1. Paste this line into c:\PCTime.vbs, then double-click the file:
msgbox Date & ", " & Time

2. Insert this formula into some cell of a blank Excel spreadsheet:
=now()

If both tests give you the correct date/time then your vendor has some
explaining to do.

 

[Meanon]

Several of my webcam programs as well as a program the controls an
Outdoor LED Display Sign like the ones you see at malls, etc.

Not sure about the specific function call but the software vendor said
they use "a standard function call to get the current time from the
operating system". I assume this would be a function call made from a
C program to a standard system DLL. According to the vendor this is a
known OS bug.

Yes, the time is automatically adjusted by the OS and the proper time
is displayed in the System Tray clock.

When I open a command prompt and echo Time=%time% it displays the
correct time.

TIA.

==============

I've heard this line a few times before: "It's a known OS bug". This is
often the first line of defense by vendors. When pressed for substantiation
of "known", they invariably fail to deliver. If this was a known bug thenit
would be widely known by know - Windows XP has been out for many years! I
recommend you run two more tests before leaning on your vendor. Both tests
obtain the OS's system time.

1. Paste this line into c:\PCTime.vbs, then double-click the file:
    msgbox Date & ", " & Time

2. Insert this formula into some cell of a blank Excel spreadsheet:
    =now()

If both tests give you the correct date/time then your vendor has some
explaining to do.- Hide quoted text -

- Show quoted text -

Both methods give the correct time, however, keep in mind the problem
only exists during the 2 week period that is different for the "new"
daylight savings time vs the previous dates. IOW, two weeks after the
time change the programs will display the correct time again. This
makes me wonder if the Microsoft DST patches or just that, a patch not
a permanent proper fix.

 

[Pegasus [MVP]]

Several of my webcam programs as well as a program the controls an
Outdoor LED Display Sign like the ones you see at malls, etc.

Not sure about the specific function call but the software vendor said
they use "a standard function call to get the current time from the
operating system". I assume this would be a function call made from a
C program to a standard system DLL. According to the vendor this is a
known OS bug.

Yes, the time is automatically adjusted by the OS and the proper time
is displayed in the System Tray clock.

When I open a command prompt and echo Time=%time% it displays the
correct time.

TIA.

==============

I've heard this line a few times before: "It's a known OS bug". This is
often the first line of defense by vendors. When pressed for
substantiation
of "known", they invariably fail to deliver. If this was a known bug then
it
would be widely known by know - Windows XP has been out for many years! I
recommend you run two more tests before leaning on your vendor. Both tests
obtain the OS's system time.

1. Paste this line into c:\PCTime.vbs, then double-click the file:
msgbox Date & ", " & Time

2. Insert this formula into some cell of a blank Excel spreadsheet:
=now()

If both tests give you the correct date/time then your vendor has some
explaining to do.- Hide quoted text -

- Show quoted text -

Both methods give the correct time, however, keep in mind the problem
only exists during the 2 week period that is different for the "new"
daylight savings time vs the previous dates. IOW, two weeks after the
time change the programs will display the correct time again. This
makes me wonder if the Microsoft DST patches or just that, a patch not
a permanent proper fix.

=====================

This is certainly a possibility but an extremely remote one. If all tests
display the correct time except for one particular program then there is a
big finger pointing right at that program. I use Kaseya, a web-based
computer administration/management program, and whenever I extract a Kaseya
report then it adjusts all event date stamps behind my back because the
server is in a different time zone than my own machine. I suspect that
something similar happens with your program. Perhaps the application
maintains a semaphore file that it reads once every hour. When it finds a
gap, caused by the Daylight Switch, then it persists for a couple weeks,
"thinking" that it missed a reading.

If you could find just one single program that is not related in any way to
your problem application and that exhibits the same problem then you would
have a good case for a Windows bug. If you can't then your case is very
weak. As I said before: There are a few million WinXP installations that
have been running since around 2001 and I am not aware of a single report
about this type of problem. Has your vendor been able to support his claim
that this is a "known bug"? If it's "known" then he should be able to
deliver the goods with ease!

 

[Meanon]

Both methods give the correct time, however, keep in mind the problem
only exists during the 2 week period that is different for the "new"
daylight savings time vs the previous dates. IOW, two weeks after the
time change the programs will display the correct time again. This
makes me wonder if the Microsoft DST patches or just that, a patch not
a permanent proper fix.

=====================

This is certainly a possibility but an extremely remote one. If all tests
display the correct time except for one particular program then there is a
big finger pointing right at that program. I use Kaseya, a web-based
computer administration/management program, and whenever I extract a Kaseya
report then it adjusts all event date stamps behind my back because the
server is in a different time zone than my own machine. I suspect that
something similar happens with your program. Perhaps the application
maintains a semaphore file that it reads once every hour. When it finds a
gap, caused by the Daylight Switch, then it persists for a couple weeks,
"thinking" that it missed a reading.

If you could find just one single program that is not related in any way to
your problem application and that exhibits the same problem then you would
have a good case for a Windows bug. If you can't then your case is very
weak. As I said before: There are a few million WinXP installations that
have been running since around 2001 and I am not aware of a single report
about this type of problem. Has your vendor been able to support his claim
that this is a "known bug"? If it's "known" then he should be able to
deliver the goods with ease!- Hide quoted text -

- Show quoted text -

Well, that is exactly what I have! ;-)

The iSpy webcam program has the same problem as the Adtron 7000
program that drives our LED sign. The two progrmas are from completely
different vendors and gave nothing in common.

However, you're right *most* programs seem to be able to get the right
time. I guess I'll continue to persue this with the Adtron 7000
vendor.

Thanks for you input!

 

[Pegasus [MVP]]

Both methods give the correct time, however, keep in mind the problem
only exists during the 2 week period that is different for the "new"
daylight savings time vs the previous dates. IOW, two weeks after the
time change the programs will display the correct time again. This
makes me wonder if the Microsoft DST patches or just that, a patch not
a permanent proper fix.

=====================

This is certainly a possibility but an extremely remote one. If all tests
display the correct time except for one particular program then there is a
big finger pointing right at that program. I use Kaseya, a web-based
computer administration/management program, and whenever I extract a
Kaseya
report then it adjusts all event date stamps behind my back because the
server is in a different time zone than my own machine. I suspect that
something similar happens with your program. Perhaps the application
maintains a semaphore file that it reads once every hour. When it finds a
gap, caused by the Daylight Switch, then it persists for a couple weeks,
"thinking" that it missed a reading.

If you could find just one single program that is not related in any way
to
your problem application and that exhibits the same problem then you would
have a good case for a Windows bug. If you can't then your case is very
weak. As I said before: There are a few million WinXP installations that
have been running since around 2001 and I am not aware of a single report
about this type of problem. Has your vendor been able to support his claim
that this is a "known bug"? If it's "known" then he should be able to
deliver the goods with ease!- Hide quoted text -

- Show quoted text -

Well, that is exactly what I have! ;-)

The iSpy webcam program has the same problem as the Adtron 7000
program that drives our LED sign. The two progrmas are from completely
different vendors and gave nothing in common.

However, you're right *most* programs seem to be able to get the right
time. I guess I'll continue to persue this with the Adtron 7000
vendor.

Thanks for you input!

====================

If you can post a step-by-step process that lets me duplicate your
observation with iSpy then I'm happy to test it myself.

 

[Meanon]

Well, that is exactly what I have! ;-)

The iSpy webcam program has the same problem as the Adtron 7000
program that drives our LED sign. The two progrmas are from completely
different vendors and gave nothing in common.

However, you're right *most* programs seem to be able to get the right
time. I guess I'll continue to persue this with the Adtron 7000
vendor.

Thanks for you input!

====================

If you can post a step-by-step process that lets me duplicate your
observation with iSpy then I'm happy to test it myself.- Hide quoted text-

- Show quoted text -

Simply install iSpy on a WinXP computer, fire it up and go to the
"Caption" tab. The default format string should already be inserted
(%B %d %Y %H:%M:%S) showing the date and time. If not, put a checkmark
in "Show caption in picture". You'll see that the time displayed in
the "Sample" field is one hour ahead of the Windows clock. You can
also publish an image to your Desktop (or wherever) and verify it
there. I have this running on two WinXP Pro machines that are joined
to our domain as well as on another computer that is part of a
Workgroup (not joined to the domain and not on the same LAN). All
exhibit the same behaviour.

Keep in mind that as I mentioned earlier, the problem only occurs
during the 2 week time period(s) between when we now switch to DST and
when we used to switch to DST. So, from the beginning of November
until the middle of November and then again in March when we switch
back.

BTW, thanks for all you input.

 

[Pegasus [MVP]]

====================

If you can post a step-by-step process that lets me duplicate your
observation with iSpy then I'm happy to test it myself.- Hide quoted
text -

- Show quoted text -

Simply install iSpy on a WinXP computer, fire it up and go to the
"Caption" tab. The default format string should already be inserted
(%B %d %Y %H:%M:%S) showing the date and time. If not, put a checkmark
in "Show caption in picture". You'll see that the time displayed in
the "Sample" field is one hour ahead of the Windows clock. You can
also publish an image to your Desktop (or wherever) and verify it
there. I have this running on two WinXP Pro machines that are joined
to our domain as well as on another computer that is part of a
Workgroup (not joined to the domain and not on the same LAN). All
exhibit the same behaviour.

Keep in mind that as I mentioned earlier, the problem only occurs
during the 2 week time period(s) between when we now switch to DST and
when we used to switch to DST. So, from the beginning of November
until the middle of November and then again in March when we switch
back.

BTW, thanks for all you input.

================

I'll check it out during the next three days.

 

[RWW-MCW]

Since the time change on Sunday my WinXP Pro computer shows the right
time in the Windows clock (in the system tray), but programs that use
a function call to get the time from the operating system are 1 hour
ahead. I recall something similar happened the last time the clocks
changed.

Does anyone know of a fix for this?

We're seeing a problem in the WMI Win32_OperatingSystem class. The
LocalDateTime is reporting an hour ahead. Anything that uses this
value is an hour off. (We first noticed it when our SCCM-based
WakeOnLAN started waking computers up an hour early.)

 

[Meanon]

We're seeing a problem in the WMI Win32_OperatingSystem class.  The
LocalDateTime is reporting an hour ahead.  Anything that uses this
value is an hour off.  (We first noticed it when our SCCM-based
WakeOnLAN started waking computers up an hour early.)

Thanks, looks like I'm not going crazy after all! Now I just have to
find a fix/patch to fix it.

 

[Pegasus [MVP]]

We're seeing a problem in the WMI Win32_OperatingSystem class. The
LocalDateTime is reporting an hour ahead. Anything that uses this
value is an hour off. (We first noticed it when our SCCM-based
WakeOnLAN started waking computers up an hour early.)

Thanks, looks like I'm not going crazy after all! Now I just have to
find a fix/patch to fix it.
============
If the class mentioned by RWW is behind this phenomenon then you should be
able to reproduce it with the .vbs code below. Note that it reports your
current time zone. If that number is incorrect then you will get incorrect
results. You can probably check this with Microsoft's TimeZone tool:
http://www.microsoft.com/downloads/...d8-f390-458d-a629-6f0258ac7cdf&displayLang=en.

Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
"SELECT * FROM Win32_OperatingSystem",,48)
For Each objItem In colItems
WScript.Echo "CurrentTimeZone: " & objItem.CurrentTimeZone
dtmLocalTime = objItem.LocalDateTime
dtmMonth = Mid(dtmLocalTime, 5, 2)
dtmDay = Mid(dtmLocalTime, 7, 2)
dtmYear = Left(dtmLocalTime, 4)
dtmHour = Mid(dtmLocalTime, 9, 2)
dtmMinutes = Mid(dtmLocalTime, 11, 2)
dtmSeconds = Mid(dtmLocalTime, 13, 2)
MsgBox "Time Zone=" & objItem.CurrentTimeZone & Chr(10) _
& "Date=" & dtmMonth & "/" & dtmDay & "/" & dtmYear & Chr(10) _
& "Time=" & dtmHour & ":" & dtmMinutes & ":" & dtmSeconds
Next

 

[Meanon]

Thanks, looks like I'm not going crazy after all! Now I just have to
find a fix/patch to fix it.
============
If the class mentioned by RWW is behind this phenomenon then you should be
able to reproduce it with the .vbs code below. Note that it reports your
current time zone. If that number is incorrect then you will get incorrect
results. You can probably check this with Microsoft's TimeZone tool:http://www.microsoft.com/downloads/thankyou.aspx?familyId=07fb0bd8-f3....

Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
   "SELECT * FROM Win32_OperatingSystem",,48)
For Each objItem In colItems
   WScript.Echo "CurrentTimeZone: " & objItem.CurrentTimeZone
   dtmLocalTime = objItem.LocalDateTime
   dtmMonth = Mid(dtmLocalTime, 5, 2)
   dtmDay = Mid(dtmLocalTime, 7, 2)
   dtmYear = Left(dtmLocalTime, 4)
   dtmHour = Mid(dtmLocalTime, 9, 2)
   dtmMinutes = Mid(dtmLocalTime, 11, 2)
   dtmSeconds = Mid(dtmLocalTime, 13, 2)
   MsgBox "Time Zone=" & objItem.CurrentTimeZone & Chr(10) _
   & "Date=" & dtmMonth & "/" & dtmDay & "/" & dtmYear & Chr(10) _
   & "Time=" & dtmHour & ":" & dtmMinutes & ":" & dtmSeconds
Next

Well I just tried it at 1:32 PM PST and it reports:

CurrentTimeZone: -480

Time Zone= -480
Date= 10/04/2009
Time=14:32:00

So it looks like it's a reproduceable bug. Now if MS only had a fix!

Thanks again for your input, Pegasus!

 

[RWW-MCW]

Thanks, looks like I'm not going crazy after all! Now I just have to
find a fix/patch to fix it.
============
If the class mentioned by RWW is behind this phenomenon then you should be
able to reproduce it with the .vbs code below. Note that it reports your
current time zone. If that number is incorrect then you will get incorrect
results. You can probably check this with Microsoft's TimeZone tool:http://www.microsoft.com/downloads/thankyou.aspx?familyId=07fb0bd8-f3....

Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
   "SELECT * FROM Win32_OperatingSystem",,48)
For Each objItem In colItems
   WScript.Echo "CurrentTimeZone: " & objItem.CurrentTimeZone
   dtmLocalTime = objItem.LocalDateTime
   dtmMonth = Mid(dtmLocalTime, 5, 2)
   dtmDay = Mid(dtmLocalTime, 7, 2)
   dtmYear = Left(dtmLocalTime, 4)
   dtmHour = Mid(dtmLocalTime, 9, 2)
   dtmMinutes = Mid(dtmLocalTime, 11, 2)
   dtmSeconds = Mid(dtmLocalTime, 13, 2)
   MsgBox "Time Zone=" & objItem.CurrentTimeZone & Chr(10) _
   & "Date=" & dtmMonth & "/" & dtmDay & "/" & dtmYear & Chr(10) _
   & "Time=" & dtmHour & ":" & dtmMinutes & ":" & dtmSeconds
Next

I should have included more detail on this. The weird part is that
the timezone and DST values are correct, in both Win32_TimeZone and in
Win32_OperatingSystem, but the LocalDateTime is an hour off. The time
shows up correctly in the Windows GUI, but the LocalDateTime value
doesn't match. Also, the time values in Win32_LocalTime are correct,
but the LocalDateTime value in Win32_OperatingSystem doesn't match.
Very strange.

 

[RWW-MCW]

I should have included more detail on this.  The weird part is that
the timezone and DST values are correct, in both Win32_TimeZone and in
Win32_OperatingSystem, but the LocalDateTime is an hour off.  The time
shows up correctly in the Windows GUI, but the LocalDateTime value
doesn't match.  Also, the time values in Win32_LocalTime are correct,
but the LocalDateTime value in Win32_OperatingSystem doesn't match.
Very strange.

More details. The value that displays in in LocalDateTime (viewed
with WMI CIM Studio) includes "...GMT-04:00". We're in the US Eastern
Time Zone and just went from Daylight to Standard time. So, the
LocalDateTime value should include "...GMT-05:00". Everywhere
everywhere else I look has the 5-hour offset. I'm seeing this on both
Windows XP SP3 and Vista SP2.

For what it's worth, the closest thing I've found that's similar to my
issue (thought not exactly) after extensive searching is this report
from back in March:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=422388

 

[Meanon]

More details.  The value that displays in in LocalDateTime (viewed
with WMI CIM Studio) includes "...GMT-04:00".  We're in the US Eastern
Time Zone and just went from Daylight to Standard time.  So, the
LocalDateTime value should include "...GMT-05:00".  Everywhere
everywhere else I look has the 5-hour offset.  I'm seeing this on both
Windows XP SP3 and Vista SP2.

For what it's worth, the closest thing I've found that's similar to my
issue (thought not exactly) after extensive searching is this report
from back in March:http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?...- Hide quoted text -

- Show quoted text -

One more data point: I'm also seeing the same results in Windows 7.

 

[RWW-MCW]

More details:

1.
The LastBootUpTime value in Win32_OperatingSystem is also an hour off.

2.
The =Now() function in Excel displays the correct time.

3.
I also get the correct time when I run the Time command in a command
prompt DOS-style shell.

4.
To prove that all other settings are correct and that there is
definitely an illogical discrepancy in WMI, I came up with the script
code below, ran it, and copied the output further below.

SCRIPT:


=========================
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
WScript.Echo "Script executed: " & Now()
WScript.Echo

Set colItems = objWMIService.ExecQuery(_
"Select * From Win32_OperatingSystem")
For Each objItem in colItems
WScript.Echo "Win32_OperatingSystem:"
WScript.Echo "Caption = " & objItem.Caption
WScript.Echo "CSDVersion = " & objItem.CSDVersion
WScript.Echo "OSArchitecture = " & objItem.OSArchitecture
WScript.Echo "ServicePackMajorVersion = " & _
objItem.ServicePackMajorVersion
WScript.Echo "ServicePackMinorVersion = " & _
objItem.ServicePackMinorVersion
WScript.Echo "Version = " & objItem.Version

strLocalDateTime = objItem.LocalDateTime
WScript.Echo "CurrentTimeZone = " & _
objItem.CurrentTimeZone
WScript.Echo "LocalDateTime = " & objItem.LocalDateTime
strTime = Mid(strLocalDateTime, 9, 2) & ":" & _
Mid(strLocalDateTime, 11, 2) & ":" & _
Mid(strLocalDateTime, 13, 2)
strDate = Mid(strLocalDateTime, 5, 2) & "/" & _
Mid(strLocalDateTime, 7, 2) & "/" & _
Left(strLocalDateTime, 4)
strTZ = Right(strLocalDateTime, Len(strLocalDateTime)-21)
dtmDateTime = CDate(strDate & " " & strTime)
Wscript.Echo "LocalDateTime = " & dtmDateTime & _
" (GMT" & strTZ & ")"
Wscript.Echo "----------"
Next

Set colItems = objWMIService.ExecQuery(_
"Select * From Win32_LocalTime")
For Each objItem in colItems
strTime = objItem.Hour & ":" & objItem.Minute & ":" & _
objItem.Second
strDate = objItem.Month & "/" & objItem.Day & "/" & _
objItem.Year
dtmDateTime = CDate(strDate & " " & strTime)
WScript.Echo "Win32_LocalTime:"
Wscript.Echo "LocalTime = " & dtmDateTime
Wscript.Echo "----------"
Next

Set colItems = objWMIService.ExecQuery(_
"Select * From Win32_UTCTime")
For Each objItem in colItems
strTime = objItem.Hour & ":" & _
objItem.Minute & ":" & objItem.Second
strDate = objItem.Month & "/" & _
objItem.Day & "/" & objItem.Year
dtmDateTime = CDate(strDate & " " & strTime)
WScript.Echo "Win32_UTCTime:"
Wscript.Echo "UTCTime = " & dtmDateTime
Wscript.Echo "----------"
Next

Set colItems = objWMIService.ExecQuery(_
"Select * From Win32_ComputerSystem")
For Each objItem in colItems
WScript.Echo "Win32_ComputerSystem:"
WScript.Echo "CurrentTimeZone = " & _
objItem.CurrentTimeZone
WScript.Echo "DaylightInEffect = " & _
objItem.DaylightInEffect
WScript.Echo "EnableDaylightSavingsTime = " & _
objItem.EnableDaylightSavingsTime
Wscript.Echo "----------"
Next

Set colItems = objWMIService.ExecQuery(_
"Select * From Win32_TimeZone")
For Each objItem in colItems
WScript.Echo "Win32_TimeZone:"
WScript.Echo "Description = " & objItem.Description
WScript.Echo "Bias = " & objItem.Bias
WScript.Echo "DaylightBias = " & objItem.DaylightBias
WScript.Echo "Daylight Month/Day = " & _
objItem.DaylightMonth & "/" & objItem.DaylightDay
WScript.Echo "DaylightName = " & objItem.DaylightName
WScript.Echo "StandardBias = " & objItem.StandardBias
WScript.Echo "Standard Month/Day = " & _
objItem.StandardMonth & "/" & objItem.StandardDay
WScript.Echo "StandardName = " & objItem.StandardName
Next
=========================



OUTPUT:
=========================
Script executed: 11/5/2009 12:29:08 PM

Win32_OperatingSystem:
Caption = Microsoftr Windows VistaT Enterprise
CSDVersion = Service Pack 2
OSArchitecture = 32-bit
ServicePackMajorVersion = 2
ServicePackMinorVersion = 0
Version = 6.0.6002
CurrentTimeZone = -300
LocalDateTime = 20091105132908.265000-240
LocalDateTime = 11/5/2009 1:29:08 PM (GMT-240)
----------
Win32_LocalTime:
LocalTime = 11/5/2009 12:29:08 PM
----------
Win32_UTCTime:
UTCTime = 11/5/2009 5:29:08 PM
----------
Win32_ComputerSystem:
CurrentTimeZone = -300
DaylightInEffect = False
EnableDaylightSavingsTime = True
----------
Win32_TimeZone:
Description = (GMT-05:00) Eastern Time (US & Canada)
Bias = -300
DaylightBias = -60
Daylight Month/Day = 3/2
DaylightName = Eastern Daylight Time
StandardBias = 0
Standard Month/Day = 11/1
StandardName = Eastern Standard Time
=========================

Note that the time and offset/bias values for LocalDateTime do not
match ANY other values.

The LocalDateTime value, and anything that uses it, are simply WRONG.
(I haven't tested the script on WinXP, but the discrepancies are
the same in XP when viewed via CIM Studio.)

I would also point out that the old time change from EDT to EST was a
week EARLIER than it is now. So, nothing will be any different in mid-
November in our area (as Meanon indicated might be the case for his
area).

Is anyone else seeing this? I would love to hear back from Pegasus or
any other MVPs... or anyone for that matter.

Thanks.

 

[Unknown]

Did you visit http://support.microsoft.com/gp/cp_dst ???

More details. The value that displays in in LocalDateTime (viewed
with WMI CIM Studio) includes "...GMT-04:00". We're in the US Eastern
Time Zone and just went from Daylight to Standard time. So, the
LocalDateTime value should include "...GMT-05:00". Everywhere
everywhere else I look has the 5-hour offset. I'm seeing this on both
Windows XP SP3 and Vista SP2.

For what it's worth, the closest thing I've found that's similar to my
issue (thought not exactly) after extensive searching is this report
from back in
March:http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?...-
Hide quoted text -

- Show quoted text -

One more data point: I'm also seeing the same results in Windows 7.

 

[Meanon]

Did you visit  http://support.microsoft.com/gp/cp_dst ???







One more data point:  I'm also seeing the same results in Windows 7.- Hide quoted text -

- Show quoted text -

Yes, but it doesn't address the proble. See RWW-MCW's reply above for
an explanation of the problem.