A quick tip for those having to coerce to and from JavaScript Date objects in Server Side Actions. The time zone of the Server Side Action JavaScript environment locale is UTC (+00:00). The time zone of the Current User does not carry into the execution environment of the Server Side Action. The synopsis is that the server has no way of knowing the origin time zone of data from any particular field of the action. After all why should it? It would be strange and error prone if the server tried to infer time zones.
The pattern I have used to handle time zones is to pass a time zone offset (hours and minutes) to the Server Side Action through a dynamic field. In turn the dynamic field can then be populated with an offset determined in the client side environment. This closes the loop and tells the server “treat the data like it is in the passed in time zone”.
I have not had a chance to investigate whether client time zone information is part of context.currentUser. Even if it was I’m not sure of the relevance for scheduled API workflows.
Sounds like an interesting use case. I’d be curious to know what’s being done in the SSA that requires the time zone of the user who initiated it.
Also, can you explain what you mean by…
In my experience, dates passed to a SSA via the action’s properties can simply be treated as JS Date objects. I’ve never had to “coerce” them.
Likewise, returning either a JS Date object or the number of milliseconds since the UNIX epoch results in a proper date data type within Bubble — again, no “coercion” needed.
Maybe I’m misunderstanding what you’re saying though.
We have to process data “scraped” from a number legacy systems that will never have the financial incentives to upgrade to modern API services. Problematically these data sources provide loosely formatted date and time labels that do not contain the timezone in which the date and time labels were generated. This results in a nasty chicken and egg problem. To determine the applicable offset to UTC (+00:00) we need to be able to pass a valid date and IANA timezone identifier to any number of API services that provide offset look-ups (offset depends on the date in the timezone because of daylight savings). However to generate a valid Date object we need to know the offset to UTC (+00:00) of the date!
Long story short we have to reverse from a fairly arbitrary text label for a time point back to UNIX milliseconds.
You’re probably already aware of libraries such as moment.js, luxon.js, and day.js. If not, it seems they might offer some helpful functionality - even if it’s just the ability to “assign” a time zone to an arbitrary date and time.
Those could all potentially get around having to make a call to an offset providing service. However we still need to pass some form of identifier of the timezone in which the data was generated because there is no information in the data which describes the timezone.
As well I am trying to keep to the idiomatic “Bubble.ioLittle Lambdas” way of building actions: do one thing and do it well. Thus if we have to pass a parameter to identify the timezone we might as well simply pass a dynamic offset parameter and then build another action that just does the offset lookup.
Perfect. Refactor to pass a dynamic string that is assumed to be a valid IANA time zone identifier. After that use .isValid() to safely return null when the date can’t be parsed in the time zone.
