My note on JS Timezone, Firebase Cloud Functions and Luxon

#firebase #javascript #luxon #datetime

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

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

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