Is it possible to have script to get 'system time' - UTC or GMT?

I have a need to get a time value that is set by the outside world, and not the user’s device. For instance, I now have people doing corona tests with my app around the world (good), but we have opening hours of 12-19 CET during this pilot phase. BUT Glide uses the user’s device to work out ‘now’ so I am getting all kinds of problems.

I know I have asked this of @Mark before… but it occurs to me that this might be a relatively easy thing for yes-code, something that could be useful for lots of apps. A script that pulls in the common time… and then once it is in Glide, magic can happen :slight_smile:

I customized Jeff’s solution to use in all my apps since this thread.

You can convert your user’s “now” to CET and then your problem will be solved.

1 Like







L + (OS/24*-1)

However as it’s summer time I believe you can try CEST instead.


Thanks - but I’m not sure if this helps. I don’t know the user offset time for all users. Plus I don’t always have the ability to get the user to do an action to pick up a timestamp I can manipulate (with a webhook - which I already use). The time for a user coming in and seeing the ‘closed’ popup is computed on the fly without a click.

Unless I’m missing something!

(And thanks for the clear explanation and walkthrough too :star2::star2:)

You don’t need the user to do anything for this to calculate. It is automatic. We take the “now” value from a math column, then the other things are template columns and math columns.

From your original post, do you mean you will show something to the user during 12-19 CET and something else during the off hours?

Yes - the system is open between 12 - 19 CET.
But a user might come in from holiday in Peru… so -7 from CET

Let’s say it is 2000 in CET.
User time for ‘now’ is 1300 Peru time.

I cannot just use a template column to pretend their time is CET. And the template column you have would compute the Time /CET Temp as user time (1300 CET). Which is wrong, as the Berlin user would see 2000 CET - which is the correct time.

Your offset counter does not work for the user. It is still processing 1300 CET… which is the wrong time. And then you are hardcoding the offset, but the offset would be different depending on the user time zone.

I solve the problem now by sending a webhook for a user action to Integromat. This then sends a CET timestamp to the User Profile table in GS. That helps for the some of my use cases, but it would be a ton easier to have this JS code to pick up the time :slight_smile: :slight_smile: less time wasted moving data about (to Integromat and GS is super fast, from GS back to Glide… 15 seconds or much, much worse).

With YC


yes, you are :wink:

The beauty of Jeff’s solution is it requires nothing from the user. It takes their “now” and through the use of a clever trick converts it to any (valid) time zone that you want.


Well if you insist…

Here’s a video to show that it works regardless of the user’s timezone. I even moved to Alaska for you.

The ‘pretend’ part here is to know if you use the current time of the user and add CEST to it then what would it convert to the user’s timezone. Glide can read that template and convert it to a datetime object.

Then we take the math column to find the offset compared to CEST and then a final math column to derive the true current CEST time.

Using this, you require nothing from the user and know their offset from a specific timezone, or in most of my cases, their timezone compared to UTC, and the “localized” time as the 4th column shows.


To make the YC column refresh, I tweaked the code a bit



Hello @Mark_Turrell

So you have the choice between 2 ways to do it
Then it is possible to complete the script with other tips and tricks

1 Like

You can use user address or current location switch to determine the time zone he is now and have a table to adjust the hours to any global time you want… if you are using my address picker… you already have a country as a last string after last coma, you can add to that script time zone value… that would be the best…because some countries have many time zones

1 Like

We should just add UTC time as a special value.


Agreed - and make it clear that there is a difference between UTC and user device time.


This is fixed now thanks to @Manu.n and his XC (Experimental Code) to pick up UTC as a value.