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.
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).
I ran into an issue with Go code, related to time zones, that would return either 1900-01-01 01:00:00 +0100 CET or 1900-01-01 00:53:28 +0053 LMT, depending on which machine it is being run:
https://play.golang.org/p/K3ceq1n1KI
I was able to rule out the Go version as source of the difference. Where does Go get its time zone information from?
Actually it depends.
Check time.LoadLocation() source and the comment above it. Particularly, it says this:
// LoadLocation looks in the directory or uncompressed zip file
// named by the ZONEINFO environment variable, if any, then looks in
// known installation locations on Unix systems,
// and finally looks in $GOROOT/lib/time/zoneinfo.zip.
And you should keep in mind that on a Unix/Posix systems (e.g. Linux), proper time zone data files are always available in "known installation locations". But on other systems there no such locations. As a result, on Windows, LoadLocation zone won't find any time zones (unless either ZONEINFO or GOROOT were configured properly) and will just use default instead (which is UTC, if my memory is correct).
However, the LMT issue you described above is a bit different beast. You see, LMT is not exactly a proper time zone. E.g. see here. And I didn't dig out where exactly it comes from, but I suspect it is related to the fact that the time zone was not established yet at the time that you're converting. So, go seems to be calculating LMT of the place instead.
For example, if you just change year from 1900 to 2000 (or even 1905) in your playground example, it will come out with correct time zone (CET).
As to the difference between machines, I'd say it's pretty arguable what is the most natural way of defining time zone rules before they were actually introduced. As a result, I would imagine that in some time zone databases, start time of the first rule in a time zone will be either omitted or adjusted to extend it further to the past. While others will put an LMT offset there instead. (Even though most if not all of them are derived from the same IANA database in one way or another.)
If you want to ensure exact same behavior on different machines, I'd say building your own zoneinfo.zip and setting ZONEINFO variable should help.
What's the correct way to get the Unix timestamp in Go? I thought it would be time.Now().Unix() but it's clearly not.
http://play.golang.org/p/KoJADUDxOS
So time.Now().Unix() tells me the unix timestamp is 1257894000 whereas my browser tells me it is 1398351437. Also www.unixtimestamp.de tells me it is 1398351704 which is what I would expect. Why is the one coming from Go so far off? I get the same results on my local machine btw.
What am I missing?
UPDATE
Ok, turns out it was really only an issue on play.golang.org. I thought I tested it locally as well but I had another look now and yes on my local machine everything is correct.
Unix() does produce a Unix timestap: The number of seconds since the epoch.
I think the documentation http://golang.org/pkg/time/#Time.Unix is pretty clear here.
Maybe you are not interested in a Unix timestamp but some human readable time? In that case use Format(): http://golang.org/pkg/time/#Time.Format
And: The playground has only synthetic time. Absolute values on the playground do not correspond to UTC.
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.