0

Somehow after a Docker image rebuild, I started having problems with javascript timezone problem. It used to work, but after a Docker image update, somehow the resulting Date object does not obey the TZ setting anymore. As the result, our timezone depending Date string formatting tests are failing.

# in the tests
console.log(new Date("2016-04-01T00:00:00.000000+00:00"));
// It is very strange it says (Asia) at the end.
// In fact, it will say whatever I put in TZ
Fri Apr 01 2016 00:00:00 GMT+0000 (Asia)

# in Chrome developer tool
console.log(new Date());
Fri Apr 01 2016 08:00:00 GMT+0800 (CST)

gulpfile.js

gulp.task('test', ['_set_tpe_timezone'], runKarmaWebpackTests);
gulp.task('_set_tpe_timezone', function() {
  gutil.log('Setting timezone TZ = Asia/Taipei');
  process.env.TZ = 'Asia/Taipei';
  return;
});

I am using the following setup to run javascript tests:

  • Gulp + Karma
  • inside a Docker container
  • In gulpfile, execute the following setting before each test process.env.TZ = 'Asia/Taipei';
  • using headless Chrome 59
  • cat /etc/timezone = Etc/UTC
Andy
  • 1,231
  • 1
  • 15
  • 27
  • What is the `Dockerfile`? What command used to start the container for testing? – Andy Shinn Jul 18 '17 at 15:08
  • This would really benefit from a [MCVE](https://stackoverflow.com/help/mcve). The above is a start, but it is not verifiable. Can you give us something that we can reproduce the problem? – Matt Johnson-Pint Jul 18 '17 at 15:15
  • 1
    One thing I can tell you is that when you see `(Asia)` in the JS Date string, it means that the `TZ` variable was interpreted as a POSIX string, rather than as an IANA TZ identifier. I can't tell you *why* without being able to reproduce the problem, but perhaps that will help somehow. – Matt Johnson-Pint Jul 18 '17 at 15:17
  • Thanks for your suggestions. During the process of trying to get a reproducible MCVE, I found the problem is on the base image I used. I will post the answer to this question and send a bug report to the phusion/baseimage team. – Andy Jul 19 '17 at 03:15

1 Answers1

0

Although the root cause is not yet discovered, a solution was found. Since this problem did not appear before, but only after a docker system prune -a, the base image was updated to the latest, which introduce this bug.

As a temporary solution, I have switch back to the old base image and it works like before without other modifications. I am going to also report this to the phusion team.

original Dockerfile

FROM phusion/baseimage
...

new Dockerfile

FROM phusion/baseimage:0.9.21
...
Andy
  • 1,231
  • 1
  • 15
  • 27