TL;DR: get the timezone abbrev and IANA name client-side from App Connect.
I’m building a validated app for user’s that both travel across multiple timezones with the same device and also for users that control other users around the globe. I’m aware that the date&time app component automatically converts user input time in accordance to the user’s current browser settings, but I need to allow users to both be aware of their current timezone setting and to override their current timezone using another and have it persist to their profile.
As a start, is anyone aware of how to format the date returned at the App Connect level to display the timezone to the user? Converting a DB UTC time to display localTime is trivial, but I’m totally stuck as to how to expose the current timezone abbreviation as well. Also, if I could somehow pull the full timezone name, I could then present it to the user as a default and allow them to re-select any of the IANA timezones and recompute the appropriate time via .addMinutes(). But I need a starting point by knowing what timezone the user happens to be in, and not just the UTCoffset as their settings are going to persist long-term (through eventual DST drifts). I do actually need to know the full IANA name (or close to it geographically).
Is anyone aware of how to do this using the current Wappler date formatters? Very much appreciated!
Bump. Again, how to display the user’s current timezone name back to them. Useful for scheduling apps where the user bounces across timezones frequently with their mobile device.
I got the override working just fine, whereby a user can statically select their timezone, but the most trivial case (a user simply using their browser default tz) is still unsolved as to how to display the user’s default tz back to them.
In all my projects that I’ve been created so far using NodeJS + PostgreSQL - timestamp is stored in DB in UTC, but displayed for user in their current time zone without any additional formatting or settings.
Yes you are correct, Wappler utilizes moment.js to perform the quiet conversion to the browser timezone from the UTC timestamp. My question is how to display that timezone that it’s automatically detecting from the browser to the user. This is a feature directly requested by the app userbase, as they are heavy travelers and/or manage accounts around the globe.
Code bellow might not the best one or might not fit your needs at all, but it displays current time zone.
Create server connect which returns variable with just NOW
Add that Server connect to your page
Add Time and Date element to your page
Page code bellow:
'Current time zone is '+(var1.datetime.formatDate('HH').toNumber()-serverconnect1.data.current_time.formatDate('HH').toNumber()>0?'+':'-')+(var1.datetime.formatDate('HH').toNumber()-serverconnect1.data.current_time.formatDate('HH').toNumber()).toString()
Thanks a bunch @Notum, I had deduced a similar way to “extract” how much the moment.js was drifting its display by, was just hoping there might’ve been a way to extract the IANA abbrev name (ex GMT or EDT, etc) for best clarity (and to handle the weird zones with half-hours) as moment.js clearly has a hold of it from the browser in order to perform its calc. Thanks a lot for your time!
@Antony only kinda-sorta. I threw most of this on the backburner for higher priorities. The crux of the issue is the moment.js library does not throw the timezone out of the box, yet it obviously utilizes it. In the interim, I have a workaround via creating an on-page variable like thus:
Which is essentially the amount of ms the client is offset from epoch when moment.js interprets the timezone of the client. I throw that to an SC that derives other things about the client, and returns the offset for the client’s visibility. This is closely-following @Notum suggestion, except in reverse so the server-side can utilize the native offset for other purposes.
The only issue is an offset (e.g. +3.5 HRS GMT) is NOT a timezone. The difference matters, especially in instances of daylight-savings observance, where an offset starts becoming ambiguous. But clients can override the “default” offset with a timezone of their choice, which I store and then perform offset drifts in Server Connects for all times displayed and interpreted thereon (this way they can claim a different timezone than the one their browser is currently reporting, and I report and ingest all times from them appropriately). Importantly, I put the onus on the DB engine (Postgres in my case) to keep the offsets updated for the various IANA timezones. This is pg_timezone_names table for those following along with Postgres.
This is getting me by for now, as the users seem not to complain, until this comes back around to my attention for a better solution. Will keep this updated in the future.
So I wanted to display the timezone abbreviation, like BST, CET etc.
Step 1 - Define a Wappler variable for the timezone
<dmx-value id="user_timezone"></dmx-value>
Step 2 - Create some JS to get the timezone
… and have the JS update the value of the variable “user_timezone” via the dmx.parse function.
(Credit to our lord and master chatGPT for the other js code)
Thanks so much @Antony for taking the time to come up with the js for this, you da man! Saved me some time for sure, thanks for sharing it. Works like a charm via page flow (I take the output via page flow and work with that rather than call the dmx.parse in-line.
A digital beer for you (or GPT?) heh.
It’d be absolute candyland if one day the Wappler forums and documentation all became part of the training data canon for GPT…