Hm, well, I know UTC conversion is an overhead compared to an all-local approach, and that’s perfectly fine by the way, as long as you know your app will always be local and all of your users will always deal with local time.
That being said, it is not actually that hard because moment-tz is really clever enough to abstract away all the details, including DST data. (PS: you are lucky you don’t live in Turkey. Out government as of last 14 years sporadically decides changing DST switching dates, abandon it altogether and then readapt it just trying to make sure if we ever send a rover to mars, it does get lost ) (PPS: I know that’s a different problem but just thought it would be cool to demonstrate how working with “interationally-absolute” data can be a life-saver at times)
Furthermore, synced-cron also does have a utc option for you to decide if you want to work with local time or utc.
In the mongo querying case, you could store the date/time information at UTC and then query them using the UTC equivalent of your local query-bounds.