I have this this date
<p am-time-ago="Thu Oct 15 21:53:55 IST 2015"></p>
it shows
[$parse:syntax] Syntax Error: Token 'Oct' is an unexpected token at column 5 of the expression [Thu Oct 15 21:53:55 IST 2015] starting at [Oct 15 21:53:55 IST 2015].
2015-10-13T18:49:52.888Z
it shows Token 'T18' is an unexpected token at column 11 of the expression [2015-10-13T18:49:52.888Z] starting at [T18:49:52.888Z].
Moment isn't parsing the date correctly because it is in an unsupported format.
For the first one, change IST to the offset (+05:30).
For the second, get rid of the T and Z, and put a space between the date and time.
Edit: Note that more recent versions of moment js don't support TZ abbreviations anymore, like IST or CST or UTC. That function was deprecated in 1.6.0.
Related
I have some graph data with date type values.
My gremlin query for the date type property is working, but output value is not the date value.
Environment:
Janusgraph 0.3.1
gremlinpython 3.4.3
Below is my example:
Data (JanusGraph): {"ID": "doc_1", "MY_DATE": [Tue Jan 10 00:00:00 KST 1079]}
Query: g.V().has("ID", "doc_1").valueMap("MY_DATE")
Output (gremlinpython): datetime(1079, 1, 16)
The error is 6 days (1079.1.10 -> 1079.1.16).
This mismatch does not occur when the years are above 1600.
Does the timestamp have some serialization/deserialization problems between janusgraph and gremlinpython?
Thanks
There were some issue with Python and dates but I would have them fixed for 3.4.3, which is the version you stated you were using. The issue is described here at TINKERPOP-2264 along with the fix, but basically there were some issues with timezones. From your example data, it looks like you store your date with a timezone (i.e. KST). I'm not completely sure, but I would imagine things would work as expected if the date was stored as UTC.
After some try & search, I found that there are some difference between java Date and python datetime. (Julian vs. Gregorian Calendar)
So I have replaced SimpleDateFormat with JodaTime and got the expected result as below:
Data (Raw): {"ID": "doc_1", "MY_DATE": "1079-1-29"}
Data (JanusGraph): {"ID": "doc_1", "MY_DATE": [Wed Jan 23 00:32:08 KST 1079]}
(I think the JanusGraph uses java Date object internally..)
Query: g.V().has("ID", "doc_1").valueMap("MY_DATE")
Output (gremlinpython): datetime(1079, 1, 29)
Thanks
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.
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)
Have a look at the year after setWeek
d = Date.today()
Wed Dec 26 2012 00:00:00 GMT+0000 (GMT Standard Time)
d.getWeek()
52
d.setWeek(52)
Mon Dec 23 2013 00:00:00 GMT+0000 (GMT Standard Time)
Anyone knows what this is about? Have I misinterpreted how the setWeek function should work?
I have found an issue in the datejs tracker with this same problem. It's from 2011, though it's still marked as new: setWeek issue
So regarding yor question of "Have I misinterpreted how the setWeek function should work?" I would say that it's a bug in the jdate code.
If you have a look at the datejs source code you will see that setWeek will always move to the Monday of the target week n:
Date.prototype.setWeek = function (n) {
return this.moveToDayOfWeek(1).addWeeks(n - this.getWeek());
};
see: datejs: svn/trunk/src/core.js