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?

"Meanon" <meanon@telus.net> wrote in message
news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com...
> 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?

On Nov 2, 3:07*pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com...
>
> > 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?

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.

"Meanon" <meanon@telus.net> wrote in message
news:7b800583-f95d-4055-b11a-3500c796b567@q40g2000prh.googlegroups.com...
On Nov 2, 3:07 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com...
>
> > 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?

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.

On Nov 2, 3:52*pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:7b800583-f95d-4055-b11a-3500c796b567@q40g2000prh.googlegroups.com...
> On Nov 2, 3:07 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
>
>
>
>
> > "Meanon" <mea...@telus.net> wrote in message
>
> >news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com....
>
> > > 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?
>
> 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.

"Meanon" <meanon@telus.net> wrote in message
news:a63508aa-9106-4088-a6ec-4f9ad212927a@f18g2000prf.googlegroups.com...
On Nov 2, 3:52 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:7b800583-f95d-4055-b11a-3500c796b567@q40g2000prh.googlegroups.com...
> On Nov 2, 3:07 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
>
>
>
>
> > "Meanon" <mea...@telus.net> wrote in message
>
> >news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com...
>
> > > 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?
>
> 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!

On Nov 3, 2:01*pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:a63508aa-9106-4088-a6ec-4f9ad212927a@f18g2000prf.googlegroups.com...
> On Nov 2, 3:52 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
>
>
>
>
> > "Meanon" <mea...@telus.net> wrote in message
>
> >news:7b800583-f95d-4055-b11a-3500c796b567@q40g2000prh.googlegroups.com....
> > On Nov 2, 3:07 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
> > > "Meanon" <mea...@telus.net> wrote in message
>
> > >news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com....
>
> > > > 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?
>
> > 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!- 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!

"Meanon" <meanon@telus.net> wrote in message
news:455b7f1c-e2c6-4531-b98e-3a9a611e5c2a@t11g2000prh.googlegroups.com...
On Nov 3, 2:01 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:a63508aa-9106-4088-a6ec-4f9ad212927a@f18g2000prf.googlegroups.com...
> On Nov 2, 3:52 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
>
>
>
>
> > "Meanon" <mea...@telus.net> wrote in message
>
> >news:7b800583-f95d-4055-b11a-3500c796b567@q40g2000prh.googlegroups.com...
> > On Nov 2, 3:07 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
> > > "Meanon" <mea...@telus.net> wrote in message
>
> > >news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com...
>
> > > > 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?
>
> > 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!- 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.

On Nov 3, 3:53*pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:455b7f1c-e2c6-4531-b98e-3a9a611e5c2a@t11g2000prh.googlegroups.com...
> On Nov 3, 2:01 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
>
>
>
>
> > "Meanon" <mea...@telus.net> wrote in message
>
> >news:a63508aa-9106-4088-a6ec-4f9ad212927a@f18g2000prf.googlegroups.com....
> > On Nov 2, 3:52 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
> > > "Meanon" <mea...@telus.net> wrote in message
>
> > >news:7b800583-f95d-4055-b11a-3500c796b567@q40g2000prh.googlegroups.com....
> > > On Nov 2, 3:07 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>
> > > > "Meanon" <mea...@telus.net> wrote in message
>
> > > >news:07a81b81-62c3-4b39-a0a4-a2d858151ccf@h14g2000pri.googlegroups.com...
>
> > > > > 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?
>
> > > 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 findsa
> > 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.- 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.

"Meanon" <meanon@telus.net> wrote in message
news:80c5e84c-3dce-49f7-96eb-1f4fdaee7327@q40g2000prh.googlegroups.com...
> ====================
>
> 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.

On Nov 2, 5:43*pm, Meanon <mea...@telus.net> wrote:
> 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.)

On Nov 4, 10:26*am, RWW-MCW <rth.wil...******.com> wrote:
> On Nov 2, 5:43*pm, Meanon <mea...@telus.net> wrote:
>
> > 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.)

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

"Meanon" <meanon@telus.net> wrote in message
news:fa091d4e-da36-4e7d-a066-0e6865ae386a@2g2000prl.googlegroups.com...
On Nov 4, 10:26 am, RWW-MCW <rth.wil...******.com> wrote:
> On Nov 2, 5:43 pm, Meanon <mea...@telus.net> wrote:
>
> > 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.)

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/t...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

On Nov 4, 11:41*am, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:fa091d4e-da36-4e7d-a066-0e6865ae386a@2g2000prl.googlegroups.com...
> On Nov 4, 10:26 am, RWW-MCW <rth.wil...******.com> wrote:
>
> > On Nov 2, 5:43 pm, Meanon <mea...@telus.net> wrote:
>
> > > 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.)
>
> 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/t...Id=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!

On Nov 4, 2:41*pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
> "Meanon" <mea...@telus.net> wrote in message
>
> news:fa091d4e-da36-4e7d-a066-0e6865ae386a@2g2000prl.googlegroups.com...
> On Nov 4, 10:26 am, RWW-MCW <rth.wil...******.com> wrote:
>
> > On Nov 2, 5:43 pm, Meanon <mea...@telus.net> wrote:
>
> > > 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.)
>
> 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/t...Id=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.