Patch :

cvs diff csv_api.php (in directory D:\CVSREPO\root1\mantisbt\core)
Index: csv_api.php

RCS file: /cvsroot/mantisbt/mantisbt/core/csv_api.php,v
retrieving revision 1.3
diff -r1.3 csv_api.php
1c1
< <?php

<?php
158c158
< return date( config_get( 'short_date_format' ), $p_date_submitted );

          return date( config_get( 'short_date_format', $p_date_submitted ) );

194c194
< return date( config_get( 'short_date_format' ), $p_last_updated );

          return date( config_get( 'short_date_format', $p_last_updated ) );

220c220
< ?>
\ No newline at end of file

malaussena,

what exactly is the problem with the date? Can you specify your bug report some more please?

Also, can you post your patch in unified diff format? I'm trying to figure out what you were tryuing to do, but I'm not sure which is the resulting revision.

This:
return date( config_get( 'short_date_format', $p_date_submitted ) );

Is certainly incorrect. config_get() takes only one parameter (in this case).

Yes. You're rigth :-(

The bug is date_submitted returned as '01/01/1970' (in french format) in the CSV export which is the default value, not the good one.
In mantis_bug_table, date_submitted is '2004-06-05 15:50:36'.

test2.csv is the export with wrong date.

Whats your short_date_format set to?

short date format is set in config_inc.php :

$g_short_date_format = 'd-m-y';

test.csv is the export file without my "wrong" fix ;-), with 01-01-70 in submitted-date.

I've tried with short-date-format set to the default value (defaults_config_inc.php).
I have the same bug.
Submitted_date still reported as 01-01-70 in the CSV export.
In the bug_view_page.php, date_submitted is correct : 06-05-04 15:50

I have the same problem with 2 install of Mantis 0.18.3

Rappel envoyé à int2str

I've tried to debug csv_export.php.

I've modified export rows like that :

# export the rows
foreach ( $rows as $row ) {
    $t_values = array();
    foreach ( $t_columns as $key => $title ) {

--> echo $key ;
--> echo ' ';
--> echo $row[$key];
--> echo $t_nl ;

check if column should be visible

        if ( !isset( $row[$key] ) ) {
            $t_values[] = '';
            continue;
        }

and I get this :

id 1
project_id 1
reporter_id 2
handler_id 0
priority 30
severity 10
reproducibility 10
version
projection 10
category
date_submitted 2004-06-05 15:50:36
eta 10
os
os_build
platform
view_state 10
last_updated 1086443436
summary L’ami « mai »
status 10
resolution 10
duplicate_id 0
fixed_in_version

As you can see, last_updated is returned as 1086443436 but date_submitted is returned as 2004-06-05 15:50:36.

So, in csv_export.php,

    $t_function = 'csv_format_' . $key;
    $t_values[] = $t_function( $row[ $key ] );

can't return a good value for date_submitted.

But... what's the problem ?

Regards.

Eric.

Rappel envoyé à int2str

I think I found a fix for my problem.

In \core\filter_api.php I've modified :

$query2 = "SELECT DISTINCT $t_select, UNIX_TIMESTAMP(last_updated) as last_updated
$t_from
$t_join
$t_where";

to :

$query2 = "SELECT DISTINCT $t_select, UNIX_TIMESTAMP(date_submitted) as date_submitted, UNIX_TIMESTAMP(last_updated) as last_updated
$t_from
$t_join
$t_where";

It seems ok for me, now...

Do you agree with me ?

In \core\filter_api.php a new correction to be compatible with the Text Search in view_all_bug_page.php :

$query2 = "SELECT DISTINCT $t_select, UNIX_TIMESTAMP(mantis_bug_table.date_submitted) as date_submitted, UNIX_TIMESTAMP(last_updated) as last_updated
$t_from
$t_join
$t_where";

UNIX_TIMESTAMP isn't used in CVS head, so this issue problem only occurs in the current release.

As far as i can tell, latest cvs does not have this issue.

I do agree with you. This only occurs in 0.18.3... but it is the last release.
At work, I can't install a CVS version ! :-(
So I had to correct this bug by myself...

This is already fixed in 0.19.0.