Bug 794654

Summary: creation_time is 0
Product: [Fedora] Fedora EPEL Reporter: Alexander Todorov <atodorov>
Component: python-bugzillaAssignee: Will Woods <wwoods>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el6CC: crobinso, wwoods
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 791181 Environment:
Last Closed: 2013-03-25 18:50:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 791181    
Bug Blocks:    

Description Alexander Todorov 2012-02-17 08:29:22 UTC
+++ This bug was initially created as a clone of Bug #791181 +++

Description of problem:

bugzilla query --reporter=atodorov --outputformat="%{bug_id} %{creation_time} %{actual_time} %{creation_ts}"
738568 19700101T00:00:00 0.0 2011.09.15 04:08
771701 19700101T00:00:00 0.0 2012.01.04 12:01
744769 19700101T00:00:00 0.0 2011.10.10 08:16
746723 19700101T00:00:00 0.0 2011.10.17 11:52
726326 19700101T00:00:00 0.0 2011.07.28 05:22
738566 19700101T00:00:00 0.0 2011.09.15 04:01
676300 19700101T00:00:00 0.0 2011.02.09 07:05
717639 19700101T00:00:00 0.0 2011.06.29 09:01
746221 19700101T00:00:00 0.0 2011.10.14 08:21
682144 19700101T00:00:00 0.0 2011.03.04 04:48
^C


The cration_time and actual_time fields appear to have 0 value. creation_ts is the field which shows when the bug was created.


1) Why are cration_time and actual_time 0?
2) What is their purpose then?

--- Additional comment from sgreen on 2012-02-16 14:47:26 EET ---

(In reply to comment #0)
> 1) Why are cration_time and actual_time 0?

I'm not seeing the same thing that you are seeing.

Take the first bug for example.

mysql> SELECT creation_ts FROM bugs WHERE bug_id = 738568;
+---------------------+
| creation_ts         |
+---------------------+
| 2011-09-15 04:08:36 |
+---------------------+
1 row in set (0.24 sec)

This is also what is shown in the web UI for this bug too,

There also appear to be no bugs with a creation date anywhere near epoch.

mysql> SELECT bug_id FROM bugs WHERE creation_ts < '1970-01-10';
Empty set (0.24 sec)

> 2) What is their purpose then?

The creation_ts value reports when the bug was reported/created. I can't see any column called actual_time (or something similar)

  -- simon

--- Additional comment from atodorov on 2012-02-16 14:56:31 EET ---

(In reply to comment #1)
> (In reply to comment #0)
> > 1) Why are cration_time and actual_time 0?
> 
> I'm not seeing the same thing that you are seeing.

Because you're specifying a different field name. creation_ts != creation_time != actual_time.

--- Additional comment from sgreen on 2012-02-16 15:04:56 EET ---

(In reply to comment #2)
> Because you're specifying a different field name. creation_ts != creation_time
> != actual_time.

Where are the creation_time and actual_time fields coming from?

  -- simon

--- Additional comment from atodorov on 2012-02-16 15:51:29 EET ---

(In reply to comment #3)

> Where are the creation_time and actual_time fields coming from?
> 

>>> import bugzilla
>>> bz = bugzilla.Bugzilla(url='https://bugzilla.redhat.com/xmlrpc.cgi')
>>> bz.getbugfields()
['external_choices', 'status_whiteboard', 'reporter_accessible', 'groups', 'cf_story_points', 'estimated_time', 'rep_platform', 'cf_regression_status', 'creation_time', 'actual_time', 'reporter_id', 'internal_whiteboard', 'flag_types', 'cf_mount_type', 'keywords', 'partner', 'summary', 'external_bugs', 'id', 'cf_extra_component', 'blocked', 'build_id', 'verified', 'cf_type', 'cclist_accessible', 'cust_facing', 'bug_status', 'short_desc', 'priority', 'bug_file_loc', 'version', 'fixed_in', 'milestone_url', 'pm_score', 'clone_of', 'release_notes', 'cf_environment', 'product', 'cf_verified_branch', 'qa_contact', 'reporter', 'conditional_nak', 'bug_severity', 'remaining_time', 'target_release', 'bug_id', 'delta_ts', 'dependson', 'creation_ts', 'cf_documentation_action', 'devel_whiteboard', 'qa_whiteboard', 'everconfirmed', 'longdescs', 'cf_extra_version', 'product_id', 'cf_crm', 'cf_last_closed', 'attachments', 'alias', 'qe_conditional_nak', 'op_sys', 'component', 'assigned_to', 'target_milestone', 'resolution', 'last_change_time', 'cc']


From what I see in the python code these values are coming from executing the getBugFields XML-RPC method.

--- Additional comment from sgreen on 2012-02-17 01:55:55 EET ---

actual_time is the value from the 'Hours Worked' column in a bug. It is an number, and most bugs in Bugzilla will report '0' as I don't believe this information is widely recorded.

creation_time is indeed the time that a bug is reported / created. The below RPC call (using perl's SOAP::Lite):

 $call = $rpc->call(
     'Bug.search_new',
     {
         reporter => 'atodorov',
         include_fields => ['id', 'creation_time', 'actual_time']
     }
 );

returns the correct information:

$VAR1 = {
          'bugs' => [
                    {
                      'creation_time' => '20070312T02:54:00',
                      'id' => '231860'
                    },
                    {
                      'creation_time' => '20070417T23:07:00',
                      'id' => '236915'
                    },
                    {
                      'creation_time' => '20070504T00:12:00',
                      'id' => '239024'
                    },
...

Unfortunately, the Red Hat Bugzilla team don't have the resources to help debug your specific code. Feel free to reopen if you believe that there is a bug within Red Hat Bugzilla itself.

  -- simon

Comment 1 Alexander Todorov 2012-02-17 08:30:54 UTC
Cloning here against python-bugzilla, which is what I was using. 

Looks like creation_time has the correct value in the database but the bugzilla command line tool returns 0. See first and last comment.

Comment 2 Cole Robinson 2012-12-30 22:04:16 UTC
This is fixed in python-bugzilla git, at least I can't reproduce with the command line you gave me.

Comment 3 Fedora Update System 2013-02-16 15:28:48 UTC
python-bugzilla-0.8.0-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-bugzilla-0.8.0-1.el6

Comment 4 Fedora Update System 2013-03-04 22:20:46 UTC
python-bugzilla-0.8.0-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-bugzilla-0.8.0-2.el6

Comment 5 Fedora Update System 2013-03-09 19:21:35 UTC
Package python-bugzilla-0.8.0-2.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing python-bugzilla-0.8.0-2.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0578/python-bugzilla-0.8.0-2.el6
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2013-03-25 18:50:57 UTC
python-bugzilla-0.8.0-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.