Render last modification (and other) dates in local time zone

[jploski]

Currently the "Last modification" date and other dates are displayed as they are stored in the database - in UTC time zone. It would be more sensible to render them in server's local time zone instead (our users complained about it).

Looking at documentation of EPrints::Time::render_date, it seems that it was intended so, but the implementation doesn't match spec. I suggest the following patch:

--- eprints-3.3.12-src/perl_lib/EPrints/Time.pm 2013-07-30 14:07:46.000000000 +0200
+++ eprints/perl_lib/EPrints/Time.pm    2014-01-21 22:35:04.000000000 +0100
@@ -419,6 +419,9 @@
        return $session->html_phrase( "lib/utils:date_unspecified" );
    }

+   # Convert UTC to local time zone, trim result to original resolution:
+   @l = @{[ local_datetime(datetime_utc(@l)) ]}[0..$#l];
+
    my( $year, $mon, $day, $hour, $min, $sec ) = @l;

    #1999

[sebastfr]

Problem is that the _render_date method may add "UTC" to the rendered date.

Might need yet another option to _render_date $utc/$local.

(note to self, for testing: $ENV{TZ} = "Pacific/Kiritimati" in session_init)

[sebastfr]

Duplicate of #174

[jploski]

I discovered a problem with my above patch. The module Time::Local used by EPrints (timegm_nocheck) is trying too hard for its own good and will interpret "1940" passed to it by the caller in form of "40" to mean "2040". I see no easy workaround for that behavior - EPrints could pass through the year unmodified, and it would help in the considered case, but then years <1000 would still be misinterpreted.

[GFournie]

Here is my workaround (in perl_lib/EPrints/Time.pm, in _render_date, around line 422).
Tested on EPrints 3.3.12.

     if( @l == 0 )
     {
             return $session->html_phrase( "lib/utils:date_unspecified" );
     }

     #### MODIF
     # print STDERR "TIME: $datevalue\n";
     # print STDERR "TIME: ( @l )\n";

     # Convert UTC to local time zone, trim result to original resolution:
     # From https://github.com/eprints/eprints/issues/194
     #  @l =  @{[ local_datetime(datetime_utc( @l)) ]}[0..$#l];
     # ===> doesn't work well ; converts 1927 to 2027 !!! :-(
     #
     # Other version from code found on Perl monks site :
     # We don't try to convert to local time if we only have a date (no hours,minutes,seconds)...
     if ( @l > 3) {
       my( $year, $month, $day, $hour, $min, $sec ) = @l;
       my $precision = $#l;

       #  proto: $time = timegm($sec,$min,$hour,$mday,$mon,$year);
       $month = $month-1 if defined $month;
       my $epoch = Time::Local::timegm($sec,$min,$hour,$day,$month,$year);

       #  proto: ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
       my ($lyear,$lmonth,$lday,$lhour,$isdst) = (localtime($epoch))[5,4,3,2,-1];

       $lyear += 1900;  # year is 1900 based
       $lmonth++;         # month number is zero based
       @l = ( $lyear, $lmonth, $lday, $lhour, $min, $sec )[0..$precision];
     }
     # print STDERR "TIMELOC: ( @l )\n";
     #### END of MODIF

     my( $year, $mon, $day, $hour, $min, $sec ) = @l;

[stweil]

@sebastfr, why was this issue closed? One of our users reported a wrong time for the "last status change" a few days ago. Obviously the time is always shown in UTC which is not what users expect: either it should be converted to the local time zone (maybe a user setting is needed for this) or there should be an indication that the time is UTC (adding that string would be sufficient).

[sebastfr]

@stweil hello, see my last comment (Jan'14) and #174 - I left eprints about two years ago, for a follow-up you may want to contact @jiadiyao or the tech mailing-list.

[stweil]

Thanks for answering. I noticed that there are two issues for the same problem, and both were closed.
@jiadiyao, IMHO one of both issues should be opened again because the problem still exists. I suggest to re-open #194 because it contains more information.
@jploski, @cmdtstof, did you find a solution for the reported issue?

[RedHaxor]

I have tested the fix that @GFournie posted above and it is displaying the dates/times correctly.
However things like the Latest additions listing will still show on the wrong days.

This is a pretty annoying issue for those of us that are in timezones far away from UTC. We are in Australia in UTC+10, so things that were added through a script at 4am this morning is showing as being added at 6pm last night.