You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
constsecondSundayMarch=newDate(Date.UTC(year,2,8));secondSundayMarch.setUTCDate(8+(7-secondSundayMarch.getUTCDay())%7);constfirstSundayNovember=newDate(Date.UTC(year,10,1));firstSundayNovember.setUTCDate(1+(7-firstSundayNovember.getUTCDay())%7);constisDST=(date)=>{returndate>=secondSundayMarch&&date<firstSundayNovember;};functionconvertToUsDenver(date){constutcDate=newDate(date.getTime());// Ensure it's a Date object in UTCconstyear=utcDate.getUTCFullYear();// Mountain Standard Time (MST) UTC -7// Mountain Daylight Time (MDT) UTC -6constoffset=isDST(utcDate) ? -6 : -7;// Convert to milliseconds and adjustconstdenverTime=newDate(utcDate.getTime()+offset*60*60*1000);returndenverTime;}constdenverTime=convertToUsDenver(newDate("2022-03-02T15:45:34Z"));console.log(denverTime.toISOString());
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.
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.
The text was updated successfully, but these errors were encountered: