I am in the Eastern time zone, but when I write a date with pandoc to a PDF's metadata, it is off by one hour.
For example if I use --metadata meta-date="2022:05:17 23:40:50-04:00" the createdate in the PDF will show 2022:05:17 23:40:50-03:00.
timedatectl shows my correct timezone:
Local time: Wed 2022-05-18 00:05:16 EDT
Universal time: Wed 2022-05-18 04:05:16 UTC
RTC time: n/a
Time zone: America/New_York (EDT, -0400)
Running exiftool -createdate="2022:05:17 23:40:50-04:00" somefile.pdf results in the correct time zone.
What am I missing with what pandoc is doing?
Related
I am using in my database for Date and Time information the following format "yyyyMMddHHmmssSSS"
20211119143315000 and UTC. This corresponds to 19th November 2021 14:33:15 and 0 milliseconds in GMT+0.
The timezone is always UTC in the database. If my localtime in GMT 1 that example will be displayed as 19th November 2021 15:33:15 local time.
I use a DateTimePicker in my dialog and succeeded to display the correct local time with the following configuration in the XML View:
<DateTimePicker id="dp_lastUsedDate" valueFormat ="yyyyMMddHHmmssSSS Z" value="{path:'mdlPRTData>mp_last_used_date'}"/>
My issue is the format of the model value after I pick a date in the dialog. After I pick a date, the format of the value in the model is changed:
My actual local time is GMT+1
Original model value: 20211119143315000
Displayed value: 19.11.2021 15:33:15
Picked value: 19.11.2021 16:33:15
new model value: 20211119163315000 +0100
what I would expect: 20211119153315000
I could not find a solution (without making an individual change and formatter functions) for this requirement.ยด
Any tipps?
formatting a moment object gives me a different result to the one I expect to see
I tried removing UTC but still don't get the result i expect
moment.utc().startOf("day").subtract(schedule.pastDays, "days")
returns date object with:
_d: Wed Jul 17 2019 00:00:00 GMT+0000 (Etc Greenwich Standard Time) {}
but formatting it:
moment.utc().startOf("day").subtract(schedule.pastDays, "days").format()
returns:
"2019-07-16T22:00:00Z"
Where did the 2hrs go that kicked the date back to the previous day?
I expected to see:
"2019-07-17T00:00:00Z" as the date object would suggest.
So if I do not specify a timezone, moment presumes utc and so adjusts when I format(). This however works and keeps the formatted time local:
var tzDay = moment().utcOffset(moment().utcOffset(), true).local()
var newDay = tzDay.format('MMDDYYYY');
console.log(newDay)
//returns today's date without any utc adjustment
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 have a test that checks to see if an item was shipped today.
let(:todays_date) {I18n.l(Date.today, format: '%m/%d/%Y')}
expect(order.shipped_date.strftime("%m/%d/%Y")).to eq(todays_date)
This test fails with the following error:
Failure/Error: expect(order.shipped_date.strftime("%m/%d/%Y")).to eq(todays_date)
expected: "10/14/2014"
got: "10/15/2014"
When I check the date in SQLite is one day ahead than the system date.
sqlite> select date('now');
2014-10-15
sqlite> .exit
u2#u2-VirtualBox:~/tools/$ date
Tue Oct 14 20:13:03 EDT 2014
I appreciate any help you can provide.
Thanks!
The documentation says:
Universal Coordinated Time (UTC) is used.
To get the time in the local time zone, use the localtime modifier:
select date('now', 'localtime');
Thanks to #CL, I resolved this. I now select all dates in UTC so that they compare.
let(:todays_date) {I18n.l(Time.now.utc, format: '%m/%d/%Y')}
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.