341542 - Include timestamp of query execution in programmatic search output (RDF, etc.)

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[Robert Elves]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

In order to reduce the number of returned results when querying for changed reports we record when the query takes then use is as starting date on the next query (start date to Now). Ideally we would like to record the actual date/time stamp used by the Bugzilla server for this query (the 'Now' value). The date stamp of the query is currently returned in the HTML output but not when RDF content type is chosen. We rely primarily on the RDF output and therefore need the time stamp to be included.

Reproducible: Always

Steps to Reproduce:
1.construct an query using rdf content type
2.
3.

Actual Results:  
Time stamp of query execution is missing.

Expected Results:  
A field indicating the time stamp used for the 'Now' of the query to be included in the body of the RDF output.

Comment 1

[Robert Elves]

Any chance of this getting attention for the next release? It would also be ideal if bz:changeddate was included by default and formatted in the proper Bugzilla last modified timestamp format (not truncated).

Comment 2

[Robert Elves]

To make query synchonization work for the Eclipse Mylyn Bugzilla connector we've resorted to using timstamps from the task data of query hits. 
This is not ideal and has the potential to caused hits/incomings to be missed by our client.  The Bugzilla html query results page includes a timestamp of the query but this is not included in the rdf output of a query which our client relies on.  Adding the timestamp of the query execution to the rdf output would help us out a great deal.  The timestamp would need to be formatted the same DELTA_TS and could an attribute on bz:result.  

Comment 3

[Mik Kersten]

Max: could you set this as blocked by bug 449137?

Comment 4

[Max Kanat-Alexander]

(In reply to comment #3)
> Max: could you set this as blocked by bug 449137?

  Done. I've also granted you editbugs so that you can do these things yourself.

Comment 5

[Robert Elves]

Max, having a query execution timestamp (and in the same format as the last modified timestamp) would greatly help us ensure accurate Task List synchronization with Bugzilla. Any chance of this making it into 3.4?

Comment 6

[Max Kanat-Alexander]

(In reply to comment #5)
> Max, having a query execution timestamp (and in the same format as the last
> modified timestamp) would greatly help us ensure accurate Task List
> synchronization with Bugzilla. Any chance of this making it into 3.4?

  Mmmm, maybe if you write the patch! :-) I bet it'd be pretty easy.

Comment 7

[Frank Becker]

Attachment: patch, V1

Comment 8

[Max Kanat-Alexander]

Comment on attachment 356438 [details] [diff] [review]
patch, V1

Any particular reason you picked that time format? (There is a default Bugzilla format, too, if you don't specify a format.)

Comment 9

[Robert Elves]

Frank, I believe we need it formatted as "yyyy-MM-dd HH:mm:ss".

Comment 10

[Frédéric Buclin]

(In reply to comment #9)
> Frank, I believe we need it formatted as "yyyy-MM-dd HH:mm:ss".

The current format returns:

<bz:query_timestamp>Wed Jan 28 2009 20:17:23 CET</bz:query_timestamp>

I doubt that's something you can parse easily. Also, is it intentional that you don't specify the timezone? Maybe having everything using UTC would be better?

Comment 11

[Frédéric Buclin]

Oh, and hurry up to update your patch. We freeze for 3.4 tomorrow.

Comment 12

[Max Kanat-Alexander]

(In reply to comment #10)
> Maybe having everything using UTC would be better?

  Only if you update the rest of Bugzilla's machine-readable output to use UTC as well.

Comment 13

[Robert Elves]

(In reply to comment #10)
> (In reply to comment #9)
> > Frank, I believe we need it formatted as "yyyy-MM-dd HH:mm:ss".
> 
> The current format returns:
> 
> <bz:query_timestamp>Wed Jan 28 2009 20:17:23 CET</bz:query_timestamp>
> 
> I doubt that's something you can parse easily. Also, is it intentional that you
> don't specify the timezone? Maybe having everything using UTC would be better?

We need the query timestamp format to match the Advanced Search > Bug Changes time input format (same as the delta_ts format) so that we can pass it  within the request url (i.e. chfieldfrom=2006-06-14 11:10)

Max, is the delta_ts format the default Bugzilla time format you mention in comment#8? If so, that would be ideal.

Comment 14

[Frank Becker]

If we use the format "yyy-MM-dd HH:mm zzzz" as SimpleDateFormat we get the time convert to the local timezone.

I did a test with PST in the Date and CET as my local timezone and this works.

Comment 15

[Frédéric Buclin]

So, what's the status of this bug? The hard freeze is this week, and from what I understand the current patch doesn't provide a usable format.

Comment 16

[Robert Elves]

(In reply to comment #15)
> So, what's the status of this bug? The hard freeze is this week, and from what
> I understand the current patch doesn't provide a usable format.

Would be great to have this included.  Frank, could you update this patch to include seconds i.e: 2009-02-09 10:48:58 PST

Comment 17

[Frank Becker]

Attachment: Patch, V2

Now the format is %Y-%m-%e %T %Z and this is what was requested in https://bugzilla.mozilla.org/show_bug.cgi?id=341542#c16

Comment 18

[Frédéric Buclin]

Comment on attachment 361447 [details] [diff] [review]
Patch, V2

>+  <bz:query_timestamp>[% currenttime FILTER time('%Y-%m-%e %T %Z') FILTER html %]</bz:query_timestamp>

Must be %d, not %e, else a space is added for days < 10. This can be fix on checkin. r=LpSolit

Comment 19

[Frédéric Buclin]

Checking in template/en/default/list/list.rdf.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.rdf.tmpl,v  <--  list.rdf.tmpl
new revision: 1.8; previous revision: 1.7
done