Backup-data panel doesn't respect time zone

danb35 · December 5, 2020, 1:03pm

Pretty much what it says on the tin. I’ve had two backups complete within the past hour. My server knows the correct time zone:

[root@neth ~]# date
Sat Dec  5 07:58:57 EST 2020
[root@neth ~]#

But it’s shown in the backup page in Cockpit in UTC:

pike · December 5, 2020, 3:47pm

Other modules of Cockpit are honoring the time zone you selected?

danb35 · December 5, 2020, 9:54pm

Yep:

dnutan · December 5, 2020, 10:52pm

It looks like a hard-coded timezone:

github.com

NethServer/nethserver-cockpit/blob/65ca65957646a6ad38672702529a7171b3967c3d/ui/src/components/system/Backup.vue#L268


    <span>{{b.props.BackupTime | cronToHuman}}</span>
  </div>
</div>
<div class="list-view-pf-additional-info">
  <div class="list-view-pf-additional-info-item">
    <span
      :title="$t('backup.last_backup_status') + ': ' + b.status.result"
      :class="['fa', b.status.result == 'success' ? 'fa-check green' : b.status.result == 'unknown' ? 'fa-question gray' : 'fa-times red', 'panel-icon']"
    ></span>
    {{b.status['last-run']
    | dateFormat}} UTC
  </div>
  <div class="list-view-pf-additional-info-item">
    <span class="fa fa-space-shuttle panel-icon"></span>
    <a
      v-if="b.props.VFSType == 'usb' || b.props.VFSType == 'cifs' || b.props.VFSType == 'nfs'"
      tabindex="0"
      class="provider-details"
      data-placement="top"
      data-toggle="popover"
      data-trigger="focus"

pike · December 6, 2020, 3:03am

Nice catch. Which developer will bring a beer to non-UTC sysadmins for this hardcording?

stephdl · December 6, 2020, 8:18pm

the JS script to determine the time from unix timestamp

github.com

NethServer/nethserver-cockpit/blob/83e92ff587690cea3b5e220d93b3b2a343fe1be4/ui/src/filters/filters.js#L91


  let hours = parseInt(Math.floor(value / 3600));
  let minutes = parseInt(Math.floor((value - hours * 3600) / 60));
  let seconds = parseInt((value - (hours * 3600 + minutes * 60)) % 60);
  let dHours = hours > 9 ? hours : "0" + hours;
  let dMins = minutes > 9 ? minutes : "0" + minutes;
  let dSecs = seconds > 9 ? seconds : "0" + seconds;
  return dHours + "h " + dMins + "m " + dSecs + "s";
},
dateFormat: function (value) {
  var moment = require("moment");
  if (+new Date(value) > 0) {
    var converted = isNaN(value) ? String(value) : String(value).length == 10 ? value * 1000 : value
    return moment(converted).format("DD MMMM YYYY, HH:mm");
  } else if (value == -1) {
    return ns._i18n.t('never_expires')
  } else return "-";
},
capitalize: function (value) {
  return value && value.toString().charAt(0).toUpperCase() + value.toString().slice(1);

danb35 · December 7, 2020, 1:40am

The UNIX timestamp should be in UTC. Wonder why it isn’t.

stephdl · December 7, 2020, 7:37am

I cannot check it now, but this is the api to find the time of the log

github.com

NethServer/nethserver-cockpit/blob/master/api/system-backup/read#L102


sub find_all_logs
{
    my $name = shift;
    my $n = "[0-9]";
    my @logs = ();
    foreach my $file (glob("/var/log/backup/backup-$name-$n$n$n$n$n$n$n$n$n$n$n$n.log")) {
        my $stat = stat($file);
        $file =~ m/-([0-9]+)\.log$/;
        my ($y,$M,$d,$h,$m) = $1 =~ /^([0-9]{4})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})\z/ or next;
        push(@logs, {"date" => "$y-$M-$d $h:$m", "path" => $file, "ts" => $stat->mtime});
    }
    return reverse sort { $a->{ts} <=> $b->{ts} } @logs;;
}
sub get_latest_stats
{
    my $name = shift;
    my %status = ('id' => $name, 'log' => '', 'last-run' => 0, 'result' => 'unknown', 'destination' => undef);

giacomo · December 9, 2020, 1:45pm

It seems that the date reported is correct, but the UTC label is wrong.
If I understand well, removing the UTC hardcoded label should be enough.

What do you think?

danb35 · December 9, 2020, 1:49pm

In order of preference, here are the options I see:

Show the correct local time, along with the correct local time zone
Show the correct UTC time, along with the UTC label
Show the correct local time with no timezone label.

The last is probably the easiest to implement, but I’d prefer either of the other two.

m.traeumner · December 9, 2020, 1:51pm

I would say the correct one is the first one.

stephdl · December 9, 2020, 3:48pm

for this one we have just to remove the UTC hardcoded label ?

pike · December 10, 2020, 6:04am

My vote goes for this.

giacomo · December 10, 2020, 7:56am

I’d say yes, because other dates on the same page doesn’t show the timezone.

If the timezone is not explicit, the time is shown in localtime, exactly how Dan was expecting.