display time in 12 hr

[aGerman]

It's always a matter of finding a command which outputs date and time in a language-independing way.
viewtopic.php?f=3&t=4555
WMIC is an easy way. The conversion between 24-hour and 12-hour clock can be done with a few lines of code, as shown above.
The only other reliable command is MAKECAB (unless you want to involve another scripting language). It seems to use the "ctime" function of the C runtime library which outputs date and time in a well-defined but rather unusual format.
viewtopic.php?p=29758#p29758

Steffen

[atfon]

WMIC is an easy way. The conversion between 24-hour and 12-hour clock can be done with a few lines of code, as shown above.
The only other reliable command is MAKECAB (unless you want to involve another scripting language). It seems to use the "ctime" function of the C runtime library which outputs date and time in a well-defined but rather unusual format.
viewtopic.php?p=29758#p29758

Steffen

Thanks. I usually utilize the WMIC method for reliability, but was not aware of that option with MAKEKAB. I'll check it out. I know this can also be done with powershell, but more fun to use "pure" batch.

[atfon]

I've noticed some strange periodic behavior with the "wmic os get localdatetime" command. From time to time, it is showing an hour behind the system time. Here I have set the prompt to display the time and then issued the wmic command:

Code: Select all

prompt $t $g

10:04:18.63 >wmic os get localdatetime
LocalDateTime
20210928090422.054000-300

I tried it again a little while later and it is showing the correct time:

Code: Select all

10:10:00.73 >wmic os get localdatetime
LocalDateTime
20210928101130.240000-240

Any theories why this may be?

Edit: It seems this may be a Windows bug which potentially makes using wmic to gather the time less reliable than previously thought: https://serverfault.com/questions/99182 ... g-timezone

[Compo]

Yes atfon, you've changed your settings between both of those examples!

It clealy shows in your two outputs, that the first item has a -300 minute offset from UTC, and the second a -240 minute offset from UTC.

The behavior you're reporting therefore is not with WMI, but with changes to your current locale between command examples, either by manual intervention ofr a bug within the Operating System..

[atfon]

Yes, you've changed your settings between both of those examples!

Actually, no I have not. See the Edit in my answer above.

[Compo]

Sorry atfon, I did not see your edit, until afterwards, either way, my point was the same, the settings changed, just not manually.

[atfon]

Sorry atfon, I did not see your edit, until afterwards, either way, my point was the same, the settings changed, just not manually.

No worries. It seems to change randomly. A search of the internet revealed this to be a more common problem than I realized. It seems that the wmic os get localdatetime is not as reliable to determine the time as we may have thought due to this Windows bug.

[atfon]

A workaround I can see is comparing the UTC Offset from wmic os get localdatetime to either the lastboottime setting or the Registry

Code: Select all

for /f "tokens=2 delims=-" %%g in ('wmic os get lastbootuptime') do for /f "tokens=1" %%h in ("%%g") do set "utcOffset=%%h"

or

Code: Select all

for /f "tokens=3" %%a in ('reg query "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v "ActiveTimeBias"') do set /a "utcOffset=%%a"
for /f "tokens=2 delims=-" %%g in ('wmic os get localdatetime') do for /f "tokens=1" %%h in ("%%g") do set "localUTC=%%h"
for /f "skip=1 tokens=2 delims=," %%g IN ('wmic os get localdatetime /Format:csv') DO for /f "tokens=1" %%h in ("%%g") do set "t=%%h"
SET "s=%t:~12,2%" & SET "m=%t:~10,2%" & SET "h=%t:~8,2%"

Once you do that, you can compare %utcOffset% to %localUTC% and if there is a discrepancy, add the appropriate amount of time to %h% and/or %m% as needed for that time zone.

[penpen]

I don't know about the bug you mentioned, so the following might or might not ne usefull.

In my experience a changing offset is caused by the "Set Time Zone Automatically" feature, which is realized by an informed guessing of your current geolocation; see:
https://docs.microsoft.com/en-us/uwp/ap ... inrt-20348.

There it is claimed:

The accuracy of the location information depends on the source. The latitude and longitude may vary within the following ranges:

• GPS : within approximately 10 meters
• Wi-Fi : between approximately 30 meters and 500 meters
• Cell towers : between approximately 300 meters and 3,000 meters
• IP address : between approximately 1,000 meters and 5,000 meters

But the accuracy also depends on how accurate the informations are retrieved using the above methods.
If your geolocation guess is based on your external IP address, then for example using a VPN (or any other gateway on the way of your IP packets) might have a huge impact, because your external IP can only be seen from pcs outside your network; so an IP packet has to be send to such an "outside PC" and if somebody replaces your outside IP with its IP, then the accuracy of that information essentially changes to "is somewhere on earth".
So especially if you don't move your PC, then you should set your timezone manually.
Hope that helps and please let me know if that stops the "drifting" timezone on your pc.


penpen

[aGerman]

I've been trying hard to reproduce this behavior without success. I mean, I'm using WMIC for so many years without facing this bug at all. However, your explanation makes perfectly sense to me, penpen. I'm wondering what other side effects it has if the time zone arbitrarily changes back and forth...

Steffen

[atfon]

I don't know about the bug you mentioned, so the following might or might not ne usefull.

In my experience a changing offset is caused by the "Set Time Zone Automatically" feature, which is realized by an informed guessing of your current geolocation; see:
https://docs.microsoft.com/en-us/uwp/ap ... inrt-20348.

penpen

Hello penpen. I enjoy your work on this forum. Thank you for your suggestions. My Time Zone is set manually, but daylight savings time is adjusted for automatically. I suspect that's the source of the issue based on the bug in newer versions of Windows 10. Here is another link to a Microsoft Forum Discussion about it:

https://docs.microsoft.com/en-us/answer ... rings.html

My Time Zone is (UTC-5) Eastern Time (US & Canada), but it is presently Daylight Savings Time. The only place where I'm seeing the drifting time zone is with the wmic os get localdatetime command. Not with any of these, for example:

Code: Select all

time /t
echo %time%
robocopy
wmic path Win32_LocalTime Get /value
wmic path win32_utctime get /value