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
Don't understand why the examples on moment-timezone page give me different result than what they say they should.
Running these statements give me date with my current local time for each instance:
var jun = moment("2014-06-01T12:00:00Z");
var dec = moment("2014-12-01T12:00:00Z");
jun.tz('America/Los_Angeles').format('ha z'); // 5am PDT **I get 7am**
dec.tz('America/Los_Angeles').format('ha z'); // 4am PST **I get 6am**
What am I missing?
Found the issue was due to missing time zone data. After loading time zone data I get the expected results, below; how to load time zone data
[http://momentjs.com/timezone/docs/#/data-loading/][1]
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 working on a script that will look up an event on a community Google Calendar (using Eastern Time Zone) and successfully convert it to the local user's timezone. Because it is a community Google Calendar, I cannot set the time to display as UTC, which would theoretically make this that much easier. Here is a step-by-step process that I am attempting to create:
Get the event time as it stands (Eastern time) from Google Calendar. This is done quite easily using the API and json format.
Get the Eastern timezone offset based on the event time using Google Maps API. Again, this is easily done.
Convert the Event time from Eastern to UTC, which I believe is done by adding the offset to the Event time.
Calculate the local timezone/UTC timezone difference based on the future date.
Return the local time for the event by adding step 4's result to the UTC event's time.
However, no matter what I do, it seems to not work the way I want it. Here is the code as it stands:
local function get_local_time(dateTime)
local xyear, xmonth, xday = string.match(dateTime, "(%d+)%-(%d+)%-(%d+)") -- Date format is displayed as yyyy-mm-dd
local xhour, xmin = string.match(dateTime, "%a(%d+):(%d+)") -- Time format is displayed as Thh:mm
local event_time = os.time({year = xyear, month = xmonth, day = xday, hour = xhour or 23, min = xmin or 59, sec = 0}) -- Gets epoch time for event time
async_ok, async = pcall (require, "async") -- Asynchronous lookup functions
if not json then json = require 'json' end
tzpage = "https://maps.googleapis.com/maps/api/timezone/json?location=28.4158,-81.2989×tamp=" .. event_time .. "&key=" .. key -- Gets offset data for Eastern Time Zone
if async_ok then
tzrpage = async.request(tzpage, "HTTPS")
end
retval, page, status, headers, full_status = tzrpage:join()
tzrpage = nil
if status == 200 then
tzopage = json.decode(page)
end
local eastern_offset = tzopage.rawOffset+tzopage.dstOffset -- Adds the offset information together (includes Daylight Savings)
local utc_event_time = event_time+eastern_offset -- Sets UTC's time for the event
local utctime, localtime = os.date("!*t", utc_event_time), os.date("*t", utc_event_time) -- Sets table data for events based on UTC's time of the event
localtime.isdst = false
local localoffset = os.difftime(os.time(utctime), os.time(localtime)) -- Sets the time difference between UTC and local time at the time of the event UTC
return os.date("%A, %B %d %Y at %I:%M%p", (utc_event_time-localoffset)) -- Should return local time of the event
end
But when I do something like the following:
print(get_local_time("2015-10-31T01:15:00"))
it returns
Friday, October 30 2015 at 02:15PM
when it should be returning
Friday, October 30 2015 at 10:15PM
as I'm Pacific time.
If I change
return os.date("%A, %B %d %Y at %I:%M%p", (utc_event_time-localoffset))
to
return os.date("%A, %B %d %Y at %I:%M%p", (utc_event_time+localoffset))
I get
Saturday, October 31 2015 at 04:15AM
Which again, is incorrect.
Where am I going wrong with this script? As a side note, the async is a client dependency, but it's essentially http.request.
Convert the Event time from Eastern to UTC, which I believe is done by adding the offset to the Event time.
Subtracting.
The offset shown in a timestamp is a signed number. It's already been "added" to UTC to generate the local time, so the inverse operation would be to subtract it. With -0400 being negative, you'd need to subtract negative 4 hours to convert back to UTC.
This question already has answers here:
Moment.js internal object what is "_d" vs "_i"
(2 answers)
Closed 6 years ago.
I'm using moment.js in my web application and encountered a bug where the time on many objects change to midnight at some point. I'm still trying to hunt down what, if anything triggers this change, but looking at one of the moments, I noticed the _i property shows the original / correct time.
Below is the developer console output of one of the moments in question, mm
_d: Thu Apr 02 2015 00:00:00 GMT-0400 (EDT)
_f: "YYYY-MM-DDTHH:mm:ssZ"
_i: "2015-04-02T12:10:43-04:00"
_isAMomentObject: true
_isUTC: false
_isValid: true
_locale: Locale
_pf: Object
_tzm: -240
mm.toISOString()
// "2015-04-02T04:00:00.000Z"
moment(mm._i).toISOString()
// "2015-04-02T16:10:43.000Z"
What does the _i represent, and why doesn't it match the string output?
It turns out the bug was caused by a combination of 2 bad assumptions I had
calling startOf() mutates the moment, which I did not realize
the Immutable data structure I'm using ignores Objects with custom prototypes, so the moment objects were left mutable
The result was that another part of the application was able to mutate moments that I expected to be immutable
To answer my question though, I found the following
_i is the input when the moment object was originally created, and does not appear to change
_d is a Date object representing the date value after any mutations
mm = moment("2015-04-02T12:10:43-04:00")
mm._i // "2015-04-02T12:10:43-04:00"
mm._d // Thu Apr 02 2015 12:10:43 GMT-0400 (EDT)
mm.startOf('day')
mm._i // "2015-04-02T12:10:43-04:00"
mm._d // Thu Apr 02 2015 00:00:00 GMT-0400 (EDT)