I have a vb6 program installed on thousands of machines, some XP and some Win7. A Win7 user has called to say that the time the program applies to its events is one hour earlier than the time on the laptop clock, which is correct. It is set to the correct time zone (Eastern) and to daylight savings time adjustment, which is the way my own Win7 machine is set up (and my own machine does not have this problem).
The line of code that obtains this time in VB6 is:
.IssueDate = Now
to put the current time and date into a member variable.
Does anyone have any ideas why a particular machine would be off by one hour, given that the clock is displaying the correct time and the time zone and DST adjustment appear correct?
I'm going to mark this one 'answered' and move on. I asked my user, diffidently, to reboot, not really expecting it to do anything; he did and said the test case he ran did not show the error. I asked him to call me the next time he used the system for its full-blown purpose, but he hasn't done so. My current suspicion is that the PC clock was off by an hour for a period this morning and he didn't notice it, he only noticed the time on the documents the application was producing.
Related
I know that you can use the time.Sleep(d Duration) function to let the Go program wait for a certain duration. Now I have the use-case that I want to keep the point in time even when the whole OS goes to sleep.
So as an example: When I sleep the go program at 1pm for two hours. And I turn off my computer on 2pm for half an hour until 2:30pm. I still want the code to resume at 3pm and not at 3:30pm.
(Of course when I sleep my OS longer than 3pm the code should resume immediately).
How should I do that with go? Is there a nice function or library for that or should I use cron as a workaround?
Banging my head on this simple date logic problem:
I know the user's time zone offset relative to UTC.
My server is in UTC. It knows the time now.
How do I calculate UTC equivalent of 'yesterday local time at 8am'?
IN JS, I tried to do it this, but it seems to not quite work.
var yesterday_am=moment(moment(new Date()).subtract(24,'hour')).format('YYYY-MM-DD'); // same local time previous day;
// when is 8am local time in utc?
var am=8 - (user.tz_offset/60);
if (am<0) { yesterday_am=moment(yesterday_am).subtract(Math.abs(am), 'hour')};
if (am>0) { yesterday_am=moment(yesterday_am).add(am, 'hour')};
For example, if UTC is 2016-01-10 0235 and local time is -7 hours, it would output 2016-1-09 1500 (8am local).
The logic you are trying to perform is impossible. Without knowing the user's actual time zone, you cannot know the UTC equivalent of 'yesterday at 8 am' local time. Daylight saving time transitions may make the offset yesterday different than the offset today. See the time zone tag wiki, particularly the Time Zone != Offset section for more information.
If you do know the user's time zone, then you can perform this calculation using the moment timezone add-on library for Moment.js. The code would be as follows:
moment().tz('America/Los_Angeles').subtract(1, 'day')
.set({hours:8, minutes:0, seconds:0, milliseconds:0}).utc()
Breaking this down so it makes sense, we are doing the following things:
moment() //get the current time
.tz('America/Los_Angeles') //put the moment in the Los Angeles time zone
//the Los Angeles time zone is one of several that are UTC-7 right now
.subtract(1, 'day') //go to yesterday
.set({hours:8, minutes:0, seconds:0, milliseconds:0}) //set the time to exactly 8 am
.utc() //convert back to UTC
Do not add 8 hours to the start of the day. This will be 9 AM if the clocks 'sprang forward' that day, and 7 am if they 'fell back'.
It sounds like your code is running in Node on the server. If it is running in the browser, then the browser knows the user's time zone rules, and you could use the following code to get the time at 8 am yesterday:
moment().subtract(1, 'day').set({hours:8, minutes:0, seconds:0, milliseconds:0}).utc()
This code does not require the moment timezone add on because the browser knows the time zone rules for the user's local time.
If you need to get the user's time zone, you have a few options. The most reliable is to use a timezone picker built into a map to let the user choose. There are a few of these floating around the internet.
If you do not want to do that, you can use the moment.tz.guess() function to have moment timezone make an educated guess about the user's time zone using some heuristics. This function is good, but due to limitations of the browser it is impossible to make it 100% accurate.
For a whole bunch of information about handling date and time and time zones in JavaScript, you can try this talk I did at JavaScript MN a few months ago.
In addition, you might like this really excellent Pluralsight course by Matt Johnson.
This code is not DST aware (in case if you've not already figure out based on the comments below). Thank you Maggie. Please refer to complete answer from Maggie.
You can do something like this
var localTime = moment.utc("2016-06-19").utcOffset('-07:00');
var utcAt8PrevDay = moment(localTime).subtract(1,'days').startOf('day').add(8, 'hour').utc();
Every couple of days (2 times a week) a desktop (Win. 7) starts up with my date-time updated. The time, date & month is correct but in year 8113. This makes several programs like Word/Excel working inappropriate & crashing.
BIOS/CMOS battery has been replaced, several antivirus programs had scanned & find find any virusses. No malware or suspicious software is installed.
Does it sounds familiar to someone ?
I would appreciate any help or advice.
Thanks !
I know you would probably like an answer that tackles the origin of your problem. Unfortunately I don't see where this could come from.
Instead, I wanted to suggest that you check your time-synchronization. Windows can sync with time servers and does so in a predefined interval.
You could try to change the time-server and to change the interval.
The time-server can be changed like this:
http://mintywhite.com/windows-7/7maintenance/windows-seven-7-sync-system-clock-with-internet-time-how-to/
The interval has to be changed by altering a registry key, namely
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
\TimeProviders\NtpClient
(It is in seconds, so 86400 is the value for an interval of 1 day!).
Maybe it's not a fix of the originating problem, but frequent updates of your system time should reduce the resulting problems.
I just noticed something strange on my WinXP SP3 PC:
When I change the sytemdate from 2 November (W.Europe Standard Time) to 2 August (W.Europe Daylight Time), Windows Explorer shows a different time in the DateModified field of all the folders and files.
For example:
I saved a file today and the value of DateModified is '02-11-2009 18:47'. But when I change the systemdate to 2 August, the value of DateModified is '02-11-2009 19:47'.
That's not what I expected !
Is there a specific reason why Windows does this ?
the file modification date is stored as GMT, but it is displayed using the current time settings. if you live in an area with daylight saving time (and i bet you are), the time switches from GMT+X+1 to GMT+X at the end of october (X depends of your time zone, it is 1 in western europe).
thus, the computer uses a different conversion when displaying a date in august and in november: this accounts for the 1 hour difference you see depending on the current date of your computer.
Windows SDK API have a set of function for converting between GMT times and time zone specific times. also, i seem to remember that the API to get file modification date always returns a GMT time. unfortunately, i don't think such tools exists for a batch file... try setting the time zone of the computer to GMT ?
I just installed update KB976098 (also KB973688 and KB973687).
The details of 'Update for Windows XP (KB976098)':
"Install this update to resolve issues caused by revised daylight saving time and time zone laws in several countries. This update enables your computer to automatically adjust the computer clock on the correct date in 2009. After you install this item, you may have to restart your computer."
I hoped that this update would solve the problem mentioned in my original question.
Unfortunately it doesn't.
To clarify, I mean time spent while the system is suspended/hibernated, not the calling thread (GetTickCount() returns the number of milliseconds since system boot).
As far as I know, GetTickCount is unrelated to threads and counts the time since the system has started. But it is better to use GetTickCount64 to avoid the 49.7 day roleover.
By the way, to get what you want you need the GetThreadTimes function. It records the creation and exit time and the amount of time the thread has spend in user or kernel space. So you have a nice way to calculate the amount of time spend.
Ok, I missed the "system" part of the question. But that is simple. When in hibernation GetTickCount continues the counting. Because people have suffered from the 49.7 days bug when the computer was in hibernate most of the time. See link text here for more information.
Short answer : Yes.
Longer answer: Read the GetTickCount() docs: It's the elapsed time since system startup, and even MS wouldn't suggest that time stands still while your computer is hibernating...
Yes, GetTickCount does include suspend/hibernate time.
In the following python script I call the Sleep API to wait 40 seconds to give me a chance to put the computer into hibernate mode, and I print the time before and after, and the tick count difference after.
import win32api
import time
print time.strftime("%H:%M:%S", time.localtime())
before = win32api.GetTickCount()
print "sleep"
win32api.Sleep(40000)
print time.strftime("%H:%M:%S", time.localtime())
print str(win32api.GetTickCount()-before)
Output:
17:44:08
sleep
17:51:30
442297
If GetTickCount did not include the time during hibernate it would be much less than the time I hibernated for, but it matches the actual time elapsed (7 minutes 22 seconds equals 442 seconds, i.e. 442000 millisecond "ticks").
For any one looking for answer under Windows CE platform, from docs:
http://msdn.microsoft.com/en-us/library/ms885645.aspx
you can read:
For Release configurations, this function returns the number of
milliseconds since the device booted, excluding any time that the
system was suspended. GetTickCount starts at 0 on boot and then counts
up from there.
GetTickCount() gives you the time in milliseconds since the computer booted. it has nothing to do with the process calling it.
No, GetTickCount() does not include the time the system spend during hibernate.
A simple test proves this.
in Python:
import win32api
win32api.GetTickCount()
-- do hibernate --
win32api.GetTickCount()
and you'll see the result...