Under /usr/share/lib/zoneinfo
I can see the following 4 different types of info for GMT
GMT
GMT+0
GMT-0
GMT0
Are there any differences between these 4 types of GMT zone times? If so, what are the differences?
I think they are all the same, or at least have the same values.
Yoo can see all here: TimeZones
On my system (and likely yours as well), GMT, GMT+0 and GMT0 are all symlinked to GMT-0. So there is no difference.
Adding to #Hasturkun's answer - on systems based on glibc, GTM, GMT+0 etc will be always symlinked, because that's how it's defined in glibc/timezone/backward mapping file. Specifically:
Link Etc/GMT GMT+0
Link Etc/GMT GMT-0
Link Etc/GMT GMT0
Link Etc/GMT Greenwich
Related
Trying to migrate from Moment.js to Dayjs but the only thing I can't get working is the Timezone abbreviation.
dayjs('2020-07-06T14:30:00.000-04:00').tz(dayjs.tz.guess()).format('Do MMM YYYY [at] HH:MMa z')
Calling the above I would expect 6th Jul 2020 at 08:07am EDT but currently I am just getting z where EDT is.
I have added the utc and timezone plugins and can't see any other plugins needed to make this work, I notice on Dayjs format docs that z isn't listed but searching the web, I see a lot of folks saying the solution is format('', {timeZone}) but the format doesn't take a second argument??
Looks like it was added to tz-plugin: https://github.com/iamkun/dayjs/pull/325/files#diff-cad460a5e46a2a48c59e95356c683820R195
Here's a code sandbox with an example of the issue:
https://codesandbox.io/s/hungry-knuth-r58gz
--- Edit
Looks like support for tz abbr was removed :(
https://github.com/iamkun/dayjs/pull/448/commits/e64c03cea79c579bcd3c4caf235b4724e56614d4
The z formatting option is added in 1.9.0 version of dayjs: https://github.com/iamkun/dayjs/pull/1069
Update the newest version and set up the plugins correctly, which should work. Example below:
var dayjs = require("dayjs")
var utc = require("dayjs/plugin/utc")
var timezone = require("dayjs/plugin/timezone")
var advanced = requires("dayjs/plugin/advancedFormat")
dayjs.extend(timezone)
dayjs.extend(utc)
dayjs.extend(advanced)
dayjs().tz('Europe/Paris').format('DD/MM/YYYY z')
I am using Splunk 6.2.X along with Django bindings to create a Splunk app.
To get access to the earliest/latest dates from the timerange picker, am using the following in my JS.
mysearchbar.timerange.val()
Am getting back a map where the values are in epoch format:
Object {earliest_time: 1440122400, latest_time: 1440124200}
When I convert them using moment using the following, I get different datetime than expected:
> moment.unix('1440122400').utc().toString()
"Fri Aug 21 2015 02:00:00 GMT+0000"
However, the time does not correspond to the values that have been selected on the time range picker i.e. 08/20/2015 22:00:00.000
Am not sure what the difference is getting caused by? Am sure tht the timezone is not the factor as the time difference is erratically not equivalent to derive using simple timezone add/subtract.
I was wondering if this behaviour can be explained as to how to get the Splunk epoch datetime to UTC would be helpful.
I was able to get rid of the timezone issue by performing the following:
Setting the timezone of the Splunk engine to UTC in props.conf as follows:
TZ = GMT
Setting up the CentOS (the server hosting Splunk) to UTC
Hope this helps anyone else who stumbles upon similar issues.
Thanks.
I'm delving into the travis-ci.org logs of a very simple app that was built to demonstrate testing and continuous integration.
I see timestamps given in each raw log file, but I don't know a simple way to convert them to readable dates?
There seem to be two different formats.
I'm on a mac, so bash or python or an online calculator answer would be terrific.
thank you!
Here are the 4 sub-builds, each for a different jvm:
4.1 https://travis-ci.org/ihassin/cucumber-jvm/jobs/40111229
travis_time:end:121a64f6:start=1415224070390184790,finish=1415224071568557470,duration=1178372680
4.2 https://travis-ci.org/ihassin/cucumber-jvm/jobs/40111230
0Ktravis_time:start:094d841c
4.3 https://travis-ci.org/ihassin/cucumber-jvm/jobs/40111231
travis_time:start:00067b60
4.4
https://travis-ci.org/ihassin/cucumber-jvm/jobs/40111232
travis_time:start:0011ba85
The timestamps are in nanoseconds. To get a normal Unix timestamp, you need to divide them by 10^6. For the value finish=1415224071568557470, for example, in JavaScript you could do:
new Date(1415224071568557470 / 1e6).toUTCString() // 'Wed, 05 Nov 2014 21:47:51 GMT'
I am debugging a program in MacOSX,
and I need that this program thinks we are one year later than the one given by the operating system.
I cannot change the time of the operation system, because I need to run a second program concurrently with the correct time.
I could modify the code of the first program to add one year each time it gets the time from the operation system, but the code is too big to do that; I prefer not to use this solution.
I heard once that there is a command in Unix to run a program with a fake/mocked time.
Do you know about it?
I haven't tried it, but libfaketime claims to do what you need.
Quoted from the website:
As an example, we want the "date" command to report our faked time. To do so, we could use the following command line:
user#host> date
Tue Nov 23 12:01:05 CEST 2007
user#host> LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="-15d" date
Mon Nov 8 12:01:12 CEST 2007
Assuming the lib works as advertised, you can trick your program into thinking it was running a year ahead using:
LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="+1y" ./your_program
What is the simplest way to get the machine's time zone as a positive or negative UTC offset, preferably using some time of shell command?
For all Unix-ish operating systems, when using the GNU date command:
date +%z
Example, for Eastern European Time (my timezone):
[moocha#helium ~]$ date +%z
+0200
If what you want is the non-summer/daylight-savings offset, you'd have to do something like:
date -d 'Jan 1' +%z
(or Jul in the southern hemisphere). This works with date from GNU coreutils, anyway.
Shockingly enough, I don't see any way to get the tm_isdst flag from date.
I figure that if worse comes to worse I can just send a request to an NTP server and take the difference of it and the current local time, but that seems kind of wasteful if the system knows its offset.