Date displayed in UTC timezone when running the date command via ssh

Is this a bug?

$ for ipaddress in $(lxc list | awk -F " " {'print $6'} | grep "^[0-9]" | grep     "10.0.5" | xargs); do ssh cmd@$ipaddress date; done
Fri Nov  2 17:14:49 UTC 2018
Fri Nov  2 17:14:50 UTC 2018
Fri Nov  2 17:14:51 UTC 2018
Fri Nov  2 17:14:52 UTC 2018
Fri Nov  2 17:14:53 UTC 2018
Fri Nov  2 17:14:54 UTC 2018
Fri Nov  2 17:14:55 UTC 2018
Fri Nov  2 17:14:56 UTC 2018
Fri Nov  2 17:14:57 UTC 2018

lxc exec date in proper timezone. Same result if I actually log in and run date manually.

$ for contname in $(lxc list -c n --format csv | xargs); do lxc exec $contname -- date;done
Fri Nov 2 10:13:33 PDT 2018
Fri Nov 2 10:13:33 PDT 2018
Fri Nov 2 10:13:33 PDT 2018
Fri Nov 2 10:13:33 PDT 2018
Fri Nov 2 10:13:33 PDT 2018
Fri Nov 2 10:13:34 PDT 2018
Fri Nov 2 10:13:34 PDT 2018
Fri Nov 2 10:13:34 PDT 2018
Fri Nov 2 10:13:34 PDT 2018
Fri Nov 2 10:13:34 PDT 2018

It’s only a problem when running date via ssh.

With SSH, by default you pass your original shell variables relating to the locale.

apparently he’s getting something different to end up with a difference. it looks like ssh is not passing along the time zone or that new shell is not getting fully initialized (.bashrc or .profile). UTC is the obvious default when date has no idea of the time zone.

I think that the OP probably got it the other way round. By default, a container gets the timezone Etc/UTC. If you SSH, then you might get sane values.

In any case, I blogged about this at

you cal also set the timezone with a file /etc/timezone and/or a symlink /etc/localtime in your image if you change or customize it.

If the container image uses systemd, then the canonical way is to use timedatectl as described in my blog post.

Obviously, the tool changes the files you mention but it’s the new interface to making system changes.

where would i have learned about this new thing? i am trying to understand where or how i missed learning about it.