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.
Related
Go version: 1.14.2
Operating system: Linux (Ubuntu)
I am working on a dynamic timezone based system in which user can set the timezone. I have a user who set the timezone to US/Pecific-New. For this timezone, the golang time package gives following error:
unknown time zone US/Pacific-New
I have researched on this and found that time package loads the timezone from the local system having file paths:
/usr/share/zoneinfo
/usr/local/go/lib/time
On these paths, on my local system as well as on staging Pacific-New is missing on both locations.
Is there a way to get Pacific-New on these locations ?
US/Pacific-New was never a "real" time zone and should not be selected on any system.
It was created to reflect a potential change to Pacific time that was never enacted into law. The idea at the time was that there would be a time zone ready in advance of the change. However, since the bill wasn't enacted this turned out to be a failed experiment. The TZDB no longer tries to create zones in speculative anticipation of future changes, but only adds or updates them when they are official or otherwise imminent.
Ultimately, US/Pacific-New was only ever a link to US/Pacific and then later updated as a link to the preferred form of America/Los_Angeles The last TZDB release to include such a link for US/Pacific-New was 2020a.
From the 2020b release notes:
The long-obsolete files pacificnew, systemv, and yearistype.sh have been removed from the distribution. (Thanks to Tim Parenti.)
You can read more about the long storied history with this link entry by searching the NEWS file in the TZDB for "Pacific-New" and "pacificnew", and by reading the 2020a version of the pacificnew file from before it was deleted.
As far as practical advice, don't set US/Pacific-New on any system. It is no longer a valid time zone identifier. The whole system will be affected by this. Switch to America/Los_Angeles instead.
Rather than time.LoadLocation() you can use time.LoadLocationFromTZData() which loads a location from the contents of a timezone file, which can contain whatever timezones you like.
You will need a correctly formatted timezone file with the timezones you wish to use, perhaps based on whatever you have in /usr/share/zoneinfo.
I am trying to get the last shutdown time of the system. I tried event log EvtQuery() method and got the value Event/System/TimeCreated/#SystemTime but it is not accurate.
I need this Time and date value:
I got value only from here, dates are the same but time is different:
Your timestamps do match, but one is in UTC (17:21:34) the other in local time (10:51:34 PM -> 22:51:34).
So it looks like your local timezone is 5:30 ahead of UTC time. So according to wikipedia that would be parts of India or Sri Lanka.
So what you have to do is convert the local time value to UTC (or the other way around) and you should see that they are the same.
There should be plenty of material for this on StackOverflow (try this search for example).
My question might be look like a Superuser question but I want to write a script or code which one modifies a time zone's time difference value ie from +2 to +3 bec. of Windows 10 computers cannot update themselves automatically. I have to install cumulative update which one larger than 1GB.
I need to modify current time zone's (Istanbul) time different value from UTC +2 to UTC +3. That's it. As a workaround we are using Moscow UTC +3.
There is no standalone update to make Istanbul UTC +3 so I am asking here where can I modify a time zone in Windows 10? There are also Windows XP boxes and imho Microsoft won't publish updates for them.
I've compared old registry data and the newer one. The only changes are under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Turkey Standart Time:
Display Name > From Istanbul +2 to Istanbul +3 and it has no effect.
TZI > This is the place I've been looking for. The data is binary.
Then I've found a utility called Windows Time Zone Editor.
I could also export timezone registry from updated Windows and import it at other machines just clicking the .reg file. It works on both XP and Win 10 (WinXP.reg and Win10.reg of course).
At the moment I don't need to code anything. I hope this information can help others in the future.
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.
I have a page displayed in classic ASP. 90% of the time the dates on the page show on users' machines as MM/DD/YY - same as the international settings in the registry for short date format. About 10% of the time this gets switched around and is presented as DD/MM/YY. After a restart of the machine MM/DD/YY is displayed again.
I assume some process has run which is changing the default date format. Any ideas on what I can do to a.) diagnose which program may be changing the date format and b.) how to ensure the default format is in place before loading my page?
Thanks in advance for your help.
This has to do with the complicated way that IIS and Windows are trying to figure out the "default" way to specify the date since you haven't explicitly set it in the code.
You can read more here on MSFT about the date format randomly changing.
You said a reboot fixes it, which to me implies someone is logging on to the machine and that person has a different date format. The reboot kicks them off, and it reverts back.
The workaround is just to set your date format explicitly in the code, but that's a different question.