It doesn’t look like there is a significant difference:
> date +%F_%X.%N; ./docker-exec date +%F_%X.%N; date +%F_%X.%N
2018-11-23_16:31:25.224591590
2018-11-23_15:31:25.373837652
2018-11-23_16:31:25.452186325
> date +%F_%X.%N; ./docker-exec date +%F_%X.%N; date +%F_%X.%N
2018-11-23_16:31:27.045086031
2018-11-23_15:31:27.220337493
2018-11-23_16:31:27.297787468
> date +%F_%X.%N; ./docker-exec date +%F_%X.%N; date +%F_%X.%N
2018-11-23_16:31:28.657464324
2018-11-23_15:31:28.812484845
2018-11-23_16:31:28.890919434
> date +%F_%X.%N; ./docker-exec date +%F_%X.%N; date +%F_%X.%N
2018-11-23_16:31:30.718951179
2018-11-23_15:31:30.891650122
2018-11-23_16:31:30.940783413
> date +%F_%X.%N; ./docker-exec date +%F_%X.%N; date +%F_%X.%N
2018-11-23_16:31:32.732510617
2018-11-23_15:31:32.911098272
2018-11-23_16:31:32.989577565
> date +%F_%X.%N; ./docker-exec date +%F_%X.%N; date +%F_%X.%N
2018-11-23_16:31:33.852015333
2018-11-23_15:31:33.980827196
2018-11-23_16:31:34.060757482
Time skew between hosts and containers shared filesystem is quite normal, you can’t do anything about that. The easiest thing is to compile on the host and not to use the container at all.
I’m certainly not switching back to developing on the host. I’ve seen many cumulative hours wasted due to “errors” coming from differences in host environments.
I have set the TZ environment variable in my development container, but it looks like the problem still exists. The date commands inside and outside show the same time and date, however.
It’s happening for files my editor should not have touched at all, including things like “/app/_build/dev/lib/my_app/.mix/compile.elixir”. Something is fishy here…
How can I find out which other process is changing the mtime?
Opening an issue sounds good, and the multi_time_warp option referred to in the documentation above may fix your problem for now. You can try starting your app with --erl "+C multi_time_warp" in the mix or iex arguments.