DEV Community

gie3d
gie3d

Posted on

My note on JS Timezone, Firebase Cloud Functions and Luxon

  • Cloud Functions: No matter what your defined region in cloud functions, the default timezone is UTC.
  • Firebase Console shows date time based on your device region setting.
  • Default Luxon .setZone (keepLocalTime: false) doesn't change the underlying timestamp
process.env.TZ = 'UTC';
const startDay = {
        seconds: 1660738904,
    };
const d1 = DateTime.fromSeconds(startDay.seconds);
const d2 = DateTime.fromSeconds(startDay.seconds)
        .startOf('day');
const d3 = DateTime.fromSeconds(startDay.seconds)
        .setZone('UTC')
        .startOf('day');
const d4 = DateTime.fromSeconds(startDay.seconds)
        .setZone('Asia/Bangkok')
        .startOf('day');

console.log(d1.toString()); // 2022-08-17T12:21:44.000+00:00
console.log(d2.toString()); // 2022-08-17T00:00:00.000+00:00
console.log(d3.toString()); // 2022-08-17T00:00:00.000Z
console.log(d4.toString()); // 2022-08-17T00:00:00.000+07:00
Enter fullscreen mode Exit fullscreen mode

From the example above, I used the default setZone to set different timezones from the same timestamp and monitor the result. On the first line, I set the console timezone to UTC to match with what has been configured on Cloud Functions.

d4 after setZone to Bangkok and set time to start of day, so it will set the time to 00:00:00 GMT+7 (it's 17:00:00 GMT+0)

The computation after setZone will respect the timezone that we set

  • startOf('day') will be start of the day based on Bangkok timezone
  • .toString() will print the time based on Bangkok timezone

Similar to d3 that the computation after setZone will respect the timezone as UTC.

However, if we use setZone('Asia/Bangkok', { keepLocalTime: true}). It will change the underlying timestamp.

process.env.TZ = 'UTC';
const startDay = {
    seconds: 1660738904,
};
    console.log(DateTime.fromSeconds(startDay.seconds).toSeconds());
// 1660738904


console.log(
    DateTime.fromSeconds(startDay.seconds)
        .setZone('Asia/Bangkok')
        .toSeconds()
);
// 1660738904


console.log(
    DateTime.fromSeconds(startDay.seconds)
        .setZone('Asia/Bangkok', { keepLocalTime: true })
        .toSeconds()
);
// 1660713704
Enter fullscreen mode Exit fullscreen mode

From the above example, the first and second give the same timestamp. But for the third, it changes the timestamp to reflect the same time with different timezone.

process.env.TZ = 'UTC';
const startDay = {
    seconds: 1660738904,
};
    console.log(DateTime.fromSeconds(startDay.seconds).toString());
// 2022-08-17T12:21:44.000+00:00

console.log(
    DateTime.fromSeconds(startDay.seconds)
        .setZone('Asia/Bangkok')
        .toString()
);
// 2022-08-17T19:21:44.000+07:00

console.log(
    DateTime.fromSeconds(startDay.seconds)
        .setZone('Asia/Bangkok', { keepLocalTime: true })
        .toString()
);
// 2022-08-17T12:21:44.000+07:00 --> try to keep the time 12:21:44 with timezone to GMT+7
Enter fullscreen mode Exit fullscreen mode

Top comments (1)

Collapse
 
joanneyohe profile image
JoanneYohe

I like to use Firebase Hosting mainly because I tested many different providers and Firebase offers an awesome speed across. Dua for relationship