I was reading about Time-Based Versioned Graphs and came across the following example:
CREATE (s1:Shop{shop_id:1})
-[:STATE{from:1388534400000,to:9223372036854775807}]->
(ss1:ShopState{name:'General Store'})
My question: how do I calculate this date? from:1388534400000,to:9223372036854775807
Those two values are timestamps which in java are the number of milliseconds since the Epoch (1/1/1970) began. The second value is the maximum Long value, the end of Java time, a long way away.
There are ways in all languages for generating these values for specific dates (beware that some will be based on seconds), there is quite a handy list on this site.
If you are not working in any particular programming language and just want to enter queries then you can use an online date converter like this one.
You can also calculate timestamps in Cypher if you are working with dates that relate to Now somehow using the timestamp() function:
CREATE (s1:Shop{shop_id:1})
-[:STATE{from:timestamp(),to:9223372036854775807}]->
(ss1:ShopState{name:'General Store'})
IIUC to is just a Long.MAX_VALUE, and from can be a result of either calling timestamp() function via Cypher or setting the property with the value of System.currentTimeMills() via Java API.
Take a look at the example: http://console.neo4j.org/?id=43uoyt (Note that you can skip setting rel.to and use coalesce when querying instead).
Related
Heading ##CALL ga.timetree.single({time: 1463659567468, create: true})
https://github.com/graphaware/neo4j-timetree
https://graphaware.com/neo4j/2014/08/20/graphaware-neo4j-timetree.html
The above link says that time is in long format YYYYMMDDHHmmss. But the time parameter doesn't make any sense and random nodes are getting generated in neo4j. enter image description here
What does the time parameter hold and what is the meaning of it?
The time parameter is a millisecond timestamp, or milliseconds elapsed since the UNIX epoch, which is an extremely common means of storing time-related data, you can find this in use in nearly every digital system.
The timestamp cited here represents "2016-05-19 12:06:07". The timetree built starts from a root (this is a modeling convenience), and then its child is the year (2016) followed by the month (5), then the date of the month (19). Looks like it didn't automatically create any nodes for time resolutions beyond that.
Keep in mind that now that Neo4j has native temporal values that you can use in Cypher and store as properties (as well as index), time trees are going to be less useful, as you can always do index lookups on indexed temporal properties.
There are still some cases where time trees can still be very useful, however, such as when you're searching for events that happened within some unit of time that disregards its parent units...such as finding events that happened on Mondays regardless of month, or on Januaries regardless of year, and so forth.
I need to develop an application which identifies the date inside the given text using some NLP approach. Let's assume I have a data in DB with dates column "from", "to" and if the text is below,
Get data between 1st August and 15th August
I need to identify the dates and form the query to retrieve the data. I used Natty NLP and I was able to identify the dates. But I'm stuck for more complex time expressions like:
Get data uploaded next week
Get data uploaded last week
Here for the first one I need to identify next week Monday's date and Sunday's date and form the query same for the 2nd one. But with Natty it gives me next week from today's date. What other solutions exist? Or do I need to manipulate the expression by coding? I am using Java.
Your questions is a bit confusing, but I guess you want to achieve two things:
Identify words that represent a time expression
Map these words to a formal machine-readable representation
If that is what you need check the duckling framework, it identifies time expressions, and it normalise them into a single unique formal date representation.
Note that you need to pass a reference date, for ambiguous time expressions.
You can run it as a service and call it from your code.
Is it possible to aggregate measurements or create custom queries beyond the standard dateFrom dateTo queries?
As an example, I have measurements which have a time delta of 1 minute (2015-01-01T05:05:00, 2015-01-01T05:05:00, 2015-01-01T05:05:00, ...) and I would like to query the measurements at 15 minute intervals (2015-01-01T05:15:00, 2015-01-01T05:30:00, 2015-01-01T05:45:00, ...)
So far I have only come up with these solutions:
Using the standard api request as in
https://tenant.cumulocity.com/measurement/measurements?dateFrom=2015-10-01&dateTo=2015-11-05
and then throwing away most of the data will use a massive amount of time loading the data.
Using cep (cumulocity event language) to generate a new measurement every 15 minutes using the nearest 1 minute measurement seems like a bit of overkill and not very elegant.
Batch requesting the exact minute
https://tenant.cumulocity.com/measurement/measurements?dateFrom=2015-11-05T05:15:00%2B01:00&dateTo=2015-11-05T05:16:00%2B01:00
which will in a massive amount of API requests and also does not seem very efficient.
Use the /measurements/series endpoint which will only give me all series, even those I do not want, as well as only having the aggregation options hourly and daily (as far as I can tell).
Is there a better way of doing this?
you have captured nearly all of the mechanisms that are currently available. There is one more possibility -- not sure if this is an option for you:
Mark the fifteenth measurement when sending it from the device, using e.g. a different type.
I would normally use 2. It's actually quite efficient, it's similar to a materialized view in traditional SQL, plus you can use the data everywhere and in all widgets.
Good luck :-)
Cheers,
André
I would prefer the CEP solution. The rule wouldn't be that complicated. You would of course then store these measurements twice which is not that nice but having your desired measurement with a specific type or fragment will give you the fastest way to query it.
Instead of copying the measurement you could just add a special fragment to the measurement every 15 min in the CEP rule. You cannot update measurements so you would have to delete the measurement incoming every 15 min and then create a new measurement with exactly the same values but add a fragement (e.g. "aggregatedMeasurement": {}).
Your query then looks like this:
https://tenant.cumulocity.com/measurement/measurements?dateFrom=2015-10-01&dateTo=2015-11-05&fragmentType=aggregatedMeasurement
One more idea for point 3:
You could use SmartREST to create a template with the query string and leave the dateFrom and dateTo as placeholders.
From the client side you then would have to make only one request using the bulking feature in SmartREST.
On the server side this would still be transformed into the single requests so you wouldn't gain anything in speed.
I have two write points for InfluxDB, one is the start and the other is the end. I just need to determine the duration between those two events, and make queries around it. InfluxDB has difference() aggregate method, but it doesn't work on the time meta field.
Is supplying a custom timestamp value the only way to accomplish this?
As per "Can I perform mathematical operations against timestamps?"
No:
"Currently, it is not possible to execute mathematical operators against timestamp values in InfluxDB. Most time calculations must be carried out by the client receiving the query results."
and yes, maybe:
The function ELAPSED() returns the difference between subsequent timestamps in a single field.
So it depends on the shape of your data.
If you write only the mentioned two entries then you can follow the below steps -
Limit the result to two (Eg: select * from timeseries limit 2)
Extract the time from the result set
Take the difference between the time
With JIRA REST API there is at least 2 ways to get an issue:
/jira/rest/api/2/issue/{issueIdOrKey}
/rest/api/2/search?jql
I use both of them in my project but they return a slightly different results for updated field for the same issue.
Get by key: 2014-07-18T17:53:02.594+0300
Search: 2014-07-18T17:53:02.000+0300
By some reason milliseconds in search response are not set. It looks like a bug for me, but maybe there is configuration setting or something?
PS: I have the latest JIRA version (6.2.6)
JQL search results are generally fetched directly from the Lucene index, which stores timestamps with only millisecond resolution, whereas fetching the actual issue gets the date directly from the jiraissue table in the database, which can have sub-millisecond resolution (at least depending on your configured database).
EDITED: I see that I misread the precision above: the timestamp returned by getting the issue returns only milliseconds (vs nanoseconds) and the JQL query returns only integer seconds (vs milliseconds), so the Lucene data type linked above is not relevant.
However, the answer is still the same: JQL gets the result from Lucene, while an issue fetch gets the value directly from the database. On further investigation of why the Lucene index is not returning milliseconds: in the JIRA source in BaseFieldIndexer.indexDateField, JIRA calls LuceneUtils.dateToString(date) to convert the created field into a value that is indexable by Lucene. The dateToString method explicitly converts the field into an integer number of seconds (lopping off any milliseconds in the process), and it then converts the number to a String representation for indexing purposes.
Odd! I checked this with a 6.2 instance and also got a difference:
JQL: updated: 2014-07-11T19:34:04.000-0500
Key: updated: 2014-07-11T19:34:04.768-0500
I bet the code that returns the list of issues from a search uses a different date formatter that clears the milliseconds, whereas the one that returns the data from a single issue doesn't do that. I don't know of any configuration setting that would affect that.
I recommend filing it as a minor bug at http://jira.atlassian.com/browse/JRA
Minor because any code that is checking something based on ms seems unwise.