NOW() function and Daylight Saving Time (1 Viewer)

Hi,
Today is the day in New Zealand when Daylight Saving Time DST returns to Standard Time ST.
I observed in my Access VBA application that at 3am, Windows 10 shifted its time back to 2am - as expected. The VBA code however, which produces a log with timestamped entries using the Now() function continued after 3am as if there was no change in system time at all. It appears that Now() is using some cached time.
Is there a way that I can force a refresh of the cached time, so that the Now() function returns the correct system time immediately when the system time changes? That way I don' have to wait until MS Access or Windows is restarted to get accurate timestamps in the log.
Many thanks for sharing your thoughts.

This is news to me. I’m not saying it’s not true, just a little surprising to hear. Did you verify this through the Immediate window?

Yes, the log that my application is producing is being identically written to the Immediate window as well as to a file.

In the meantime, I found a (perhaps unrelated and quite old [2009]) message stating that .Net is caching the system time as well, and showing the same behaviour.

See Stackoverflow.com
/questions/296918/net-datetime-now-returns-incorrect-time-when-time-zone-is-changed

I don't know whether Access and .Net are related behind the scenes?

Hmm
I just issued this in my immediate window.
Bottom is the current time in the UK, the other line is after I changed the timezone
Changing the time manually has the same effect.

? now()
07/04/2019 06:52:13
07/04/2019 08:51:28

I had to check, changing my timezone back and forth and Now() gives the correct results:

Thank you everyone, very helpful, but something at my end seems to differ to produce your same expected results.

The Windows event shows the time change: (at 3am back to 2am: end of DST)
The system time has changed to ‎2019‎-‎04‎-‎06T14:00:00.006044100Z from ‎2019‎-‎04‎-‎06T14:00:00.006044100Z.
Change Reason: System time adjusted to the new time zone.
Process: '' (PID 4).

The application log file shows:
--> System is active and Log has been updated at 2019-04-07 02:59:50
--> System is active and Log has been updated at 2019-04-07 03:01:04
--> System is active and Log has been updated at 2019-04-07 03:04:03
… etc.
This did not reflect the system time until I restarted the Access application.

My VBA code is in an endless loop, checking remote Internet data every few minutes and updating the local database. Could it be that the Now() function does cache the date/time while a sub is looping, but not otherwise?

EDITED: Well, just tried that last point. When I manually change the timezone while VBA is looping trough printing Now(), then it correctly shows the changed timezone time. Hence, it must be something else.
What puzzles me is that the above Windows Event is showing the very same changed to/changed from time zones.:banghead:

Just to confirm what the others have said.
I have an app with a built in date/time label updated every second.
I changed the time manually & then modified the timezone in Windows settings
The time updated immediately in each case

Attached is a simple utility I created for another user recently.
It should also update automatically & instantly

If that works, the problem is in your app.
If mine also fails its a Windows issue on your PC

Hope that helps

Thank you isladogs for the form. Works fine on my Win10 Pro with MS Access 2007, and also on a Win10 Home with MS Access Runtime.

Looks like you say, there's something wrong in the application. I'll update here when I find out what it is …

Many many thanks to all who helped me get to this point.

I have not been able to shed any light on why my log timestamp using the Now() function remained unchanged when the system clock went backwards an hour. If I manually change the time or timezone, the Debug.Print Now() correctly reflects the change in time. Can't figure out what happened that day DST ended. May have to leave it at that.
Thanks anyway for the helpful replies.

Got to admit, Sorrento, that your time issue is bizarre. However, I was able to find an article that claims that Now() doesn't update when used in a query unless you refresh the query. I don't know if it applies or not because it was for a deprecated web app, but it WAS a reference to the Access Now() function. Also, you said you were using it for logging, which I think would have to do a refresh anyway when you created the log entry.

If you were getting time from a captured value rather than using the Now() function in the query or VBA that does the logging, I could understand a delay in correcting the time maybe a little bit. However, if you use Now() it supposedly directly reads the system internal time structure that is updated every second. Further, you said it updated the visible Windows clock. Both Now() and a visible system clock would read the same exact source. Therefore, I'm still scratching my head on this one.

Thank you The_Doc_Man. A bizarre issue indeed.

My app does not use the now() function in a query, nor use a captured value, making it impossible for me to work out why this was happening.

What puzzles me also is the Windows 10 Event:
"The system time has changed to ‎2019‎-‎04‎-‎06T14:00:00.006044100Z from ‎2019‎-‎04‎-‎06T14:00:00.006044100Z."
That lists the exact same changed from and to time ….???, but I find the same entry on all my PCs where the DST time change was actioned correctly.

A mistery indeed.

You SHOULD see that message - with to/from times being different - at ANY time change including if you manually adjusted it. The fact that the to/from times matched is truly bizarre. Further, that format suggests that the time "flip" logged the system's crystal clock time, which is that precise on modern systems. Actually, it logged the UTC time, which can be as precise as noted based on the system's internal crystal clock.

By any chance are you in a local active domain? Because if so, it would be interesting to know whether any other machines noted the logging anomaly.

I researched the topics of Windows Timer Internals and related keyword searches. All I found were several articles that talked about how the system clocks link to various other services. For instance, the system clock drives the quantum process timers that assure fair distribution of processor time among multiple competing processes. I found a few articles on Windows Time Service, which emulates but doesn't exactly match Network Time Protocol (NTP). I know NTP because my mainframe used it so I understood what it said. But found no surprises in any of that research. I mention it as a "negative impact" result because I never found anything other than your .NET article that could explain the effect you saw.

For other members, here is the fully-formed link to the article Sorrento mentioned that claims that it is the time-zone info that is cached.

https://stackoverflow.com/questions...urns-incorrect-time-when-time-zone-is-changed

This is getting more bizarre as we go. Thank you The_Doc_Man. It's also getting rather technical, so I hope I can grasp your comments and reply in a meaningful manner.

My machines are in a home network, no domain server as such. Just a home router which does the DHCP and some local host name resolution too. In the same network, I have 4 machines in total, 3x Win10 and 1x Win7. Win7 and 1 of the Win10 machines correctly show a different from/to time in the event log. The remaining 2 Win10 machines (1 is Pro and 1 is Home) show the exact same from/to time. One of these machines was running overnight when the DST change occurred, the other was in Sleep mode and when I woke it up in the morning, it created that odd event entry, but showed the correctly adjusted system time in the desktop taskbar. Bizarre!

UPDATED: Just saw that the event entry repeats 4 times, with matching from/to time. The event intervals are 7 secs, 7 mins, 4 secs, and these intervals are also reflected in the matching from/to time. It looks like the system "tried/succeeded"??? 4 times to adjust the time zone ...

Does that answer the questions you kindly asked?

BTW: Thank you for listing the fully-formed link - I am not allowed to post links yet.

Now I'm REALLY confused after doing a bit more research. I had forgotten something. You saw this message:

The system time has changed to ‎2019‎-‎04‎-‎06T14:00:00.006044100Z from ‎2019‎-‎04‎-‎06T14:00:00.006044100Z.

Click to expand...

If I read this article correctly, you should have seen exactly that.

https://www.galsys.co.uk/news/just-ntp-time-servers-deal-daylight-savings-time-changeovers/

But did you see any message for a Daylight Savings Time change that had DIFFERENT to/from numbers? Because, you see, a Daylight/Standard change should NEVER adjust the time string that ends with a Z, because that is a designation for ZULU or UTC time. That NEVER changes for Daylight/Standard. What is SUPPOSED to happen is that the clock logs the local time at which the ST/DST change occurs, and that is based on a Windows localization setting. Zulu time should stay the same every time.

What the system clock reported in the log file therefore isn't an issue IF it is reporting in Zulu time. What shows on your clock in the task bar or on-screen in a clock gadget? Different story.

So on the two machines that didn't hiccup on the time change, did THEY show the same from/to time in the logs for the time change? If not, were they logging in Zulu time (with the Z on the end)? If they were NOT using Zulu time, then from/to should differ. If they WERE using Z-time, they should not differ.

Interesting and helpful stuff, The_Doc_Man! Thank you!

The two machines that did not hiccup: They show a single event each referring to DST change, showing a different from/to time, and both ending in Z.

The two machines that did hiccup: They show multiple events each referring to DST change, showing the same from/to time, and all ending in Z.

All 4 machines have settings set to adjust DST changes automatically, but NOT to adjust timezones automatically.

And the WindowsTime service is set to Start 'Manual(Triggered)' on all 4 machines.

It does not make any sense at all to me.

What I also noticed is that on other days, unrelated to DST, I get event log entries where the from/to time differs by a few seconds, also ending in Z. I guess that is when the system adjusts its clock to the web time server to stay accurate. So I think it is safe to ignore these entries, right?

Ah, I just found the oddest log entries on both machines that did hiccup:

12 hours too late, i.e. UTC+12, which happens to be our time zone in New Zealand, there is a log entry on both these machines that adjusts the time by 1 hour backwards!!!

In other words, just after 2 PM (!), the clock goes back one hour.

Sorry, I cannot post links, so I include the XML output of the log: Note the UTC time at 2am, which is our 2pm local time. Bizarre.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Kernel-General" Guid="{a68ca8b7-004f-d7b6-a698-07e2de0f1f5d}" />
<EventID>1</EventID>
<Version>2</Version>
<Level>4</Level>
<Task>5</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000010</Keywords>
<TimeCreated SystemTime="2019-04-08T02:17:34.336654700Z" />
<EventRecordID>14762</EventRecordID>
<Correlation />
<Execution ProcessID="9792" ThreadID="5288" />
<Channel>System</Channel>
<Computer>StickIT</Computer>
<Security UserID="S-1-5-21-771297527-2667789001-794917093-1001" />
</System>
- <EventData>
<Data Name="NewTime">2019-04-08T02:17:34.336000000Z</Data>
<Data Name="OldTime">2019-04-08T03:17:46.598911300Z</Data>
<Data Name="Reason">1</Data>
<Data Name="ProcessName">\Device\HarddiskVolume3\Windows\System32\SystemSettingsAdminFlows.exe</Data>
<Data Name="ProcessID">9792</Data>
</EventData>
</Event>

And that happened both on the machine that never sleeps, and on the machine that was asleep that night DST changed.

What could be different on these two machines compared with the other two that worked fine?

The simplest answer of the bunch is, when you see a from/to time and they differ by a little bit (on the order of a couple of seconds or less) then you are seeing something called clock discipline. Yes, that is the result of communing with the chosen reference time server. If you always see the changes in the same direction (doesn't matter which one) then you could safely say your system clock is running fast or slow. If it "bobbles" back and forth, that is just issues in minor clock "hiccups" and it is normal. You will see a clock that is close to accurate and communing to an NTP reference bobble a little bit ahead or behind the correct time. Overcorrects, then undercorrects in a never-ending cycle.

The Windows Time Service setting you report is, I think, normal for a non-domain setup. Many services are set for Manual or Triggered starts. So that is no surprise.

The time change events that logged different times (both ending in Z) are confusing because Zulu time should not change. LOCAL time should change. Actually, what REALLY changes, as near as I can tell, is the Time Zone Offset.

Time Services track Zulu time. Some folks call that Greenwich Mean Time but I'm an ex-Navy contractor and they use Zulu. Your system's regional settings define the current time zone as hours ahead or behind GMT/Zulu. So for example, in winter my home town of New Orleans is GMT+6 (6 hours later than GMT) but in summer, we are GMT+5.

What I just said is the way it is supposed to work. You compute the time of day based on the system binary clock. That fills in a Time Block with Year, Month, Day, Hour, Minute, Second, and (for UTC) fractions of a second. Then when you have the Zulu time figured out, you find the slot that tracks hours and adjust that according to your offset. So when it is Noon GMT, in winter it is 6:00 AM CST (New Orleans time zone). According to the NTP protocol standards, that is actually the way it is supposed to be done.

Daylight Savings Time therefore really only adds or subtracts 1 to/from the Time Zone Offset value and then just re-syncs the GMT that stands behind it all. But I have to admit I'm baffled by having two machines log the Zulu time as changing and two that DON'T log Zulu time as changing.

I have to admit I don't know where to go with this. All the research I've done so far shows that the ones with from/to times the same and suffixed with Z are the correct ones as noted earlier. The fact that you have two other machines that behave differently just blow me away, particularly since of the four machines, three are Win10.

Thank you, very clear explanations of the many aspects of system time I never thought about before. You clarified a lot of things on how they "normally" work.

The different behaviour of the 4 machines remains a mystery. You've helped me to get a better understanding, and maybe the time will come we'll understand what's happening on these machines .