(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

(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.

(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

(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.

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