Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performant way to do Timezone date conversions with LLRT missing Intl #814

Open
Brody8TY opened this issue Feb 2, 2025 · 1 comment
Open

Comments

@Brody8TY
Copy link

Brody8TY commented Feb 2, 2025

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
Copy link
Contributor

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()); 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants