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.
Related
https://github.com/influxdata/telegraf/pull/1557
Apparently some people have been asking for this, and this Github PR is the closest thing I can find to a solution, but it was ultimately denied(I think?).
Basically, I have a JSON object I'm getting from Stackdriver, which includes a Timestamp in ISO8601, which I convert to Unix time. I can insert the entire JSON response into Influx fine, but the timestamp from Stackdriver appears as a tag for a series, rather than the index of the time series itself. As a result, it is unfeasible to query by Stackdriver's provided timestamp. I could simply just drop it, and use the Influx provided timestamp, but it is essentially querying incorrect/imprecise data.
Does anyone have a clever way to approach this?
tl;dr How can I use Telegraf to override InfluxDB's timestamps with my own timestamps?
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).
I'm currently interested in automation of some of our processes, so I need to query JIRA with REST. What I want to have in response is timespent of all users for a certain date. So I use the following queries:
search?jql=project=%my_project%22&updated>startOfDay(-1d)&updated<endOfDay(-1d)&fields=worklog
search?jql=project=%my_project%22&updated>%222014-08-19%22
but in response I get a lot of worklogs which was updated not only the date I pass as argument but a month before or a day after.
So I have several questions:
Am I understand right that if I track time for some issue then the updated field will be changed?
It is likely that my queries return issues which was updated for a given date in the first place. I mean if issue was updated - return it, but issue itself contains a lot of worklogs for some period of time (month I guess).
If it is true then can I limit worklogs for the issues for only given dates?
Thanks!
Yes, you are right, you can limit your query in a way like this. But I guess your syntax is invalid.
First, in both of your query, after the project part of the JQL, there's a single percentage sign, which cannot be interpreted as a char. I'm sure you wanted to write %22 there. (However, you can completely omit %22 char)
Second, the JQL part of your query string must be formed with the official JQL syntax in mind. That means when you use logical operators, like AND, then you must write that in the middle of the query. And also don't replace > with >. So, instead of
project=my_project&updated>%222014-08-19%22
the query must look like
project=my_project AND updated>2014-08-19
Note: & sign can only split the official query string parameters of the request.
I know there was a lot of discussion about datetime parsing in dygraphs and problems with Javascript. But still, I have a problem how to correctly pass datetime.
I'm using dygraph to show data (points with 5 seconds interval) and it's crucial to have correct datetime. But if I pass datetime as timestamp (1401580800) or as ISO 8601 (2014-06-01T00:00:00+00:00), I always get datetime modified to my local time.
My question is, how to correctly pass the datetime to dygraph so datetime doesn't change?
Dygraphs use Javascript Dates, which display according to your local timezone (unfortunately, there's no way to display them using an arbitrary timezone).
One solution is to modify the data - I've encountered a similar problem in my own work, and I made a small helper function to make fake Javascript UTC dates (basically ending up with a Javascript date that's actually the wrong time but shows up looking correct when displayed in local time). This worked for my application, which used moments (http://momentjs.com/) to represent dates everywhere unless required by some other library to use Javascript's Dates.
Another (probably more correct) solution is to modify Dygraph's functions to display the right things, as demonstrated in the answer to this post: Dygraph showing dates in an arbitrary Timezone
The JavaScript Date object will always use the local time of the computer it's running on. If you don't want that behavior, you'll need to use something else. Consider building a pre-formatted string using something like moment.js and then just pass the string to dygraphs instead of the date.
I'm trying to find all WorkItems that were assigned to a person X in the last 30 days.
The big problem I have is the "in the last 30 days"-part.
I thought about using the "ever" or "asof" keywords, but couldn't find a good answer yet.. something like WHERE [Assigned To] = 'X' AND (([Assigned To] != 'X') asof '<30daysago>').
But this is still not a bulletproof solution.
Any better ideas?
Thanks & kind regards
Simon
It appears that this is not possible using just WIQL, but you can get close.
The keyword #Today will give you today's date, then just subtract your range from it. The EVER keyword applied to [Status]='AssignedTo' and a comparison against a date 30 days in the past to [StateChangeDate] is what you'll need to accomplish this.
As close as you can get with WIQL and existing fields:
This says, from all revisions (status changes) return records where the user 'X' has ever been AssignedTo and the State has changed in the last 30 days. This will basically give you a slightly fuzzy picture of what your User has been working on in the last month.
WHERE [Microsoft.VSTS.Common.StateChangeDate] >= #today - 30
AND [System.AssignedTo] EVER 'Bennett Aaron'
ORDER BY [System.State]
Add the missing field:
You could add a custom field called AssignedDate that is captured during the New->AssignedTo workflow transition that you create in the Work Item Definition XML. You can accomplish this using the Team Foundation Server Power Tools extension to Visual Studio. This would give you exactly what you need as well as additional reporting options going forward.
TFS API
I cannot help you with this one, but I believe you could query using the TFS API.
A couple of quick gotchas I've experienced to save you time on ASOF and EVER:
AsOf won't help you by itself with this as it does not support a range of dates. It allows you to query as if it were another date. In other words, if you forgot to capture the results of a query yesterday, you can use an AsOf query to get the results that you would have gotten had it run yesterday. What I understand is that you want to query a basic date range.
EVER might not work as you expect against dates as I believe it uses the exact value of the field (timestamp portion of the date field would be included) it tests with. Just make sure the EVER keyword is used against the status field rather than a date.