Hello and a happy and hopefully healthy 2022 to you all!
I am despirately trying to work with dates with timezone support in Realm functions. Unfortunately I always get the error “Intl is not defined”, meaning the node environment is lacking support of DateTime standard functions.
I`ve tried different polyfills via npm as a workaround, but without any luck.
Is there a security concern, which led you to disable / not support Intl in the functions environment or could this maybe be enabled in a future version of the functions?
Intl seems like a fairly common package and is supported by most browsers and by node since v6. What I’ve tried so far:
luxon
moment
moment-timezone
Intl polyfill
full-icu polyfill
If the issue could not be resolved, I’d have to look for other alternatives (lambda, netlify, etc.), but that would contradict the value of the MongoDB eco system. Especially since other packages are working just fine.
Could you please help me or point me in the right direction?
const {DateTime} = require('luxon');
let dt = DateTime.now().setZone('Europe/Berlin').toISO();
We are trying to calculate time differences of JS date objects across timezones, because we are building a rather complex crew scheduling system.
Talking about the ongoing project, will there be a major change or is there maybe even a quick fix? Maybe another underlying node environment with Intl support as flag enabled?
We would like to use the luxon library in realm functions, maybe there’s another workaround for timezone support?
Thanks in advance! Looking forward to hearing from you.
Best
Mathias
Apologies for the delay in getting back to you. Unfortunately, there isn’t any quick fix for this. The support for Intl is an ongoing project but we may not have an ETA available yet and some libraries providing time zone support still rely underneath on Intl.
Not ideal, but could you check if there can be APIs available to resolve time differences or work with timezones in general?
In our case, external APIs are not suitable for the task, I’m afraid, since outgoing calls generate a lot more overhead than the simple on-machine timezone calculation. Especially for hundreds of date objects per calculation.
As a workaround, we’ve resorted to generating an aggregation pipeline, which takes in all date objects via an {$addFields: …} stage and then calculates the correct timestamps via a {$dateToString: …} stage, but that seems very hacky.
A more direct solution via Intl in the near future would be much appreciated!
