Performant way to do Timezone date conversions with LLRT missing Intl

[Brody8TY]

First off, amazing work with LLRT, it's performance is amazing! Currently the biggest use-case preventing me from using LLRT with more of my lambda's is the missing Intl library. I've played around with various polyfill libraries(@formatjs, Intl) and their performance is really bad. Adding in a simple timezone conversion from UTC to America/Denver adds over 1.2 seconds to the execution time. I'm curious if adding Intl support is on the road map, I wasn't able to find it anywhere on some of the published roadmaps. If Intl is not on the road map I'm curious if anyone has found clever solutions to date timezone conversion. I actually don't need any localization, I just need to be able to use a library like dayjs and convert a date into the appropriate timezone and perform common operations like startOf('day') Here is an example.

import dayjs from 'dayjs';
import timezone from 'dayjs/plugin/timezone';

const date3 = dayjs('2022-03-02T15:45:34Z').tz('America/Denver').startOf('day');

console.log(date3.toISOString()); //2022-03-02T07:00:00.000Z

Pretty much every date library I've looked at just uses Intl under the hood to perform this type of operation.

Let me know if you have any guidance for this use-case.

[richarddavison]

I suspect the extrame performance hit is a huge lookup table of timezone data needs to be parsed. Doing so in a non-JIT runtime is not feasible. Will you always convert from UTC to America/Denver? Can you do this without a library?

Including full intl support in LLRT is desirable but adds a lot of weight to the runtime

const secondSundayMarch = new Date(Date.UTC(year, 2, 8));
secondSundayMarch.setUTCDate(8 + (7 - secondSundayMarch.getUTCDay()) % 7); 
const firstSundayNovember = new Date(Date.UTC(year, 10, 1));
firstSundayNovember.setUTCDate(1 + (7 - firstSundayNovember.getUTCDay()) % 7);
const isDST = (date) => {
  return date >= secondSundayMarch && date < firstSundayNovember;
};

function convertToUsDenver(date) {
  const utcDate = new Date(date.getTime()); // Ensure it's a Date object in UTC
  const year = utcDate.getUTCFullYear();
 

  // Mountain Standard Time (MST) UTC -7
  // Mountain Daylight Time (MDT) UTC -6
  const offset = isDST(utcDate) ? -6 : -7;

  // Convert to milliseconds and adjust
  const denverTime = new Date(utcDate.getTime() + offset * 60 * 60 * 1000);
  return denverTime;
}

const denverTime = convertToUsDenver(new Date("2022-03-02T15:45:34Z"));
console.log(denverTime.toISOString()); 

[Sytten]

I think we should consider a way for the user of LLRT to specify at runtime which modules they want to load.

But yeah an Intl module would be nice.

[ahaoboy]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

https://github.com/yt-dlp/yt-dlp/wiki/EJS#external-js-scripts-setup-guide

yt-dlp-ejs also need this API.