I am currently using the below code to return a date format from a XP embedded machine, it is a fairly basic version of XP, the below code returns the correct format on a windows 7 machine (10-02-2015) but on the XP machine it returns (Tue), how can I modify the code to return the correct format, without changing the XP time format on the machine
Set timestamp=%DATE:/=-%
The date format includes the day-of-week at the beginning in many environments - use:
set DT=%DATE:/=-%
set timestamp=%DT:~4%
to set timestamp the way is on your Win7 environment; however, this approach is not exactly portable, just be aware.
EDIT
This will reorder the date and time to something that sorts properly ... and it does happen to also be the order used in Europe:
set DT=%DATE:/=-%
set timestamp=%DT:~10,4%-%DT:~4,5%
keeping in mind, this still isn't portable across systems.
EDIT
Whoop, you wanted UK, which isn't the same as other places - that would be:
set timestamp=%DT:~7,3%%DT:~4,3%%DT:~10,4%
Related
This question already has an answer here:
get current location region from local system [closed]
(1 answer)
Closed 2 years ago.
I want to get a system's timezone information in tz database format, e.g. "America/New_York". Also I want it to be platform independent, e.g. code should work on Windows, Linux and MacOS.
Tried two recipes:
viaLocation := time.Now().Location().String() // Gives "Local"
viaZone, _ := time.Now().Zone() // Gives "EST"
"EST" is somewhat better, is there any way to map it into "America/New_York"?
I don't mind migrating to Go 1.15 and import time/tzdata
You can't do this reliably.
On Linux the local time is typically configured via /etc/localtime. The file format doesn't include the IANA name.
But even if it did, that's not the only way to configure the time zone. An obvious alternative is the TZ environment variable. I can set TZ to, say, UTC+4, so my local time zone doesn't have a name at all. This is a trivial example, but the TZ value can be much more complicated too.
The time/tzdata package is only used if the system doesn't provide time zone definitions, so importing that package doesn't help either.
Marc's answer to a similar question shows how you can take a guess on Linux (and possibly MacOS), but it's nothing more than that.
So you see, it can't be done reliably on Linux at least. I assume MacOS works similar. I don't know how local time works on Windows, but I'm sure it's possible to configure a fixed UTC offset too, i.e. a nameless time zone.
So i need to script setting the system datetime from commandline (CMD.exe, BATCH possible) but im facing difficulties with time zones vs UTC and such.
My datetime source is UTC, which is the most portable and therefor makes sense.
Originally this code was implemented using (and equivalent for date part)
cmd.exe /C time HH:mm
which seems to work by setting the time and date but expects local time, so with respect to configured time zone. Since UTC is fed in, the result is mostly wrong and only sometimes right, depending on the time zone combination.
Since accessing system properties via WMIC is popular for getting the time (the time format is explained e.g. here and here), i cheerfully looked at the verb set instead of the widely used get and tried (from a cmd.exe started as Administrator):
C:\>wmic os get localdatetime
LocalDateTime
20180119112409.189000+060
C:\>wmic os set localdatetime=20180119122400.000000+060
Updating property(s) of '\\HOST\ROOT\CIMV2:Win32_OperatingSystem=#'
Property(s) update successful.
C:\>wmic os get localdatetime
LocalDateTime
20180119112438.447000+060
The set reports it was successful yet the value is not updated. The question here arises if one can provide +000 to signal that the time is UTC or if that would set localtimezone as well.
I have seen a different property regarding the time so i tried
C:\>wmic path win32_utctime set Hour=11
Updating property(s) of '\\HOST\root\cimv2:Win32_UTCTime=#'
ERROR:
Description = Provider is not capable of the attempted operation
What i can think of is get the UTC offset in a batch script via
C:\>wmic os get currenttimezone
parse the absolute value, apply it to the UTC datetime i have as input. Then split and use time and date again but this seems too tedious for such an easy task.
I dont have access to Powershell, the solution should be as portable as possible (will have to run on WindowsPE as well, with full wmic support enabled).
I'm testing our infrastructure using the powershell command:
[System.TimeZoneInfo]::Local.Id
Which returns a string like
Eastern Standard Time
Our servers are all english right now, but I'm pretty sure this test would fail if I ran it on a non-english windows.
Is there a way to check the timezone without having to check it against an English string?
Rather than using [System.TimeZoneInfo]::Local.Id use [System.Timezoneinfo]::Local.BaseUtcOffset which will give you the result in terms of the number of hours difference between UTC time and the timezone of the server you are working with.
EDIT
#LotPings is correct that the BaseUtcOffset will not take into account DST, which may not matter if you are only concerned with verifying the timezones have not changed from your standard but if it is important you can instead use [System.TimeZoneInfo]::Local.GetUtcOffset($(get-date)) which will get you the current UTC offset.
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.
I have a program (jhead) that compiles with very few tweaks for both Windows and generic Unix variants. From time to time, windows users ask if it can be modified to also set the "creation date/time" of the files, but I don't see a way to do this with the POSIX api. What I'm currently doing is:
{
struct utimbuf mtime;
mtime.actime = NewUnixTime;
mtime.modtime = NewUnixTime;
utime(FileName, &mtime);
}
Ideally, struct utimebuf would just have a creation time, but it doesn't. It strikes me it would take a lot of windows specific, non-portable code to change the creation time under Windows. Is there another POSIX way of doing this? Any suggestions?
POSIX only recognizes three different file times:
atime (access time): The last time the file was read
mtime (modification time): The last time the file was written
ctime (attribute change time): The last time the file's metadata was modified
Any other file times that may exist in the underlying OS require OS-specific API calls in order to be modified.
And don't worry about creating non-portable code; only these times really exist under most *nix variants.
The Win32 API for this isn't really all that bad, as Windows APIs go: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724933%28v=vs.85%29.aspx . The trickiest thing is to work out how many seconds Windows thinks there were between 1st January 1601 and 1st January 1970; the rest is straightforward.