Daylight Saving Time UTC

After creating the module, would I then just change the following in the AccessUpdaterF?

    ' an update is coming, run updater
    If Abort Then Exit Sub
    LastUpdate = CurrentUTC()
    DoSaveSettings

I'm still looking for some additional assistance with the issue of multiple time zones, since I cannot figure out how to implement the Daylight Saving Time UTC code into the AccessUpdater.  I currently have 14 people using a split database with some in Central Time and some in Mountain Time.  What do I need to change in the AccessUpdater to account for the different time zones so that the Updater will work?  I've looked at the Daylight Saving Time video but I'm not understanding what to do.
Any help would be greatly appreciated!

That's a tough one. I never expected people to be in different time zones using Updater. I'd suggest converting all of the times to UTC like Alex suggested. That way you all have ONE standard time as far as the Updater is concerned. You'd have to just find the calls in my code that relate to date/time values.

I spent considerable time looking at this but I don't think it will work since your DSTcode depends upon a Const UTC_OFFSET.  Since I have users in both Central Time and Mountain Time, the offset will then be 6 or 7.  If I set the offset to CT, then when I send out the FE update, it won't be correct for the MT users.  
Is there another way to have a FE that I send out through Updater that can read the actual UTC?
Maybe I'm missing something here...which is entirely possible.

To be honest, I don't know why the updater does not work for me for my Mountain Time folks.  
It's far to complex for me to figure out.  Perhaps it's time for some paid tech support.  Let me know if you can help me out with this as I would really like get this working.

I tested this today again with a user in another time zone and it worked!  So I'm not confident that it is because of the time difference.  Is it possible that it would be because a user missing an update, and I issued another one prior them updating to the first one?  Last week, I had two users that were on version 6 when I had just issued version 9, so I had to send them version 9 for them to install manually.  One of those same users I tested today by pushing out version 10 and it worked for him.  So, I'm still confused on what the problem is.   I absolutely love the functionality of the Updater but just need to figure out why it doesn't work some times.

This is almost impossible for me to troubleshoot FROM HERE. Without playing with your setup, it's tough to tell what the problem is. I can tell you that even if a machine misses an update, it should still pick up the next one. That rarely happens, but it's possible.

Yea I can confirm that there is no error that I've seen in "missing" an update. There are times I've pushed out an update for one user to do something and I tell them to restart access to update, than a minute later they call and say "i want this too", then "can you make the font bigger", etc., and I'll push out 4-5 updates in a matter of minutes. The other PCs have no problem coming back the next time they're restarted and grabbing the version that's 5 updates later.

The only thing I can think of would be to set the developer machine intentionally in the future so that all of the rest of the machines are behind it in time. This way ANY time you push an update, ALL of the machines will think it's new. IDK though. I didn't build this with WAN users in mind. I figured everyone would be in the same physical location.

Maybe I'm missing something in the conversation here.
Disclaimer - I don't know if this will work but...  (maybe this is an Occam's razor thing)

If the problem is in the people in different time zones, having different times and converting it, my thought is:  
Don't convert it.  
Why not just use UTC without an offset?

If I look at the time in Colorado and it is 05:00 UTC and Richard, in Ft Meyers FL, looks at the time at the same moment it's still going to be 05:00 UTC.
There ya go.  Our computers are now on the same time.  It wouldn't matter what we perceive the time to be locally.

Am I all wet in my thinking?

No, you're correct. UTC is the best way to do that. But you'd have to convert everything in the database to UTC then.

Thank you guys for all the responses.  I had first thought that it was the time zone issue but Im in CT as the admin (with some users) and the rest of the users are in MT. So my machine is always on hour ahead. (or in the future)  Trying it now a couple of times, updating a users in MT has worked. Go figure. So the cause of the non-updating issue remains a mystery to me since I cannot recreate the problem.
If Im able to recreate it Ill come back and report it then.  Maybe something got corrupted and one of the many new installs corrected it. ??
Thanks again for your time. Much appreciated.  Again, love this little program so worth the money!!

Glad you like it... and the Gremlins have decided to take a nap... for now. :)

Update
I believe I have now fixed all the issues with all the users of the database and they are now able to automatically update the front in using the AccessUpdater.
I believe the issue had nothing to do with your AccessUpdater database but had to do with the installation and the users following my instructions closely.
It came down to the fact that they had to click on enable content a couple of times during the installation and failed to do that. I havent been able to get my IT to allow trusted locations so that is what Im dealing with.
Bottom line, its working perfectly for all 16 users across two times zones in two different states.
Im a happy camper now!

Awesome. I'm glad you figured it out. One of the problems with unpolished "version 1" software is that it is lacking in some areas, such as a pretty user setup interface. I'm counting on the fact that the only people who buy this are EXPERIENCED developers who can deal with issues like that. Good to know for the next version. But yes, trusted locations are key!