Fun Share: Yet another unix time converter in pure thunkable, no JS, no API

i want to share this one single block of thunkable code that does one thing only: convert a unix time (in seconds since 1970) into a readable date. for example 1655438752 would convert to 2022-06-16 21:05:52 PDT .

you call the routine as shown below:

i live in california which is offset from GMT by -7 hours, hence i can customize the converter to give results in local time.

here’s the project link:


This is super cool

Does this account for leap years and daylight savings time? A timezone is different than an offset.

Leap years, yes. However DST and time zone logic seem difficult to do. Maybe there’s an api you can call at start that returns GMT offset and time zone at your current location. Maybe it can return the human readable date at the same time! Haha!


JS has the function. All what is required is a simple Thunkable block that accepts JS code. That’s it. Tons of issues will get resolved by such block


didn’t you already make this block? you shared this project a couple of months ago.

you just construct your javascript code and pass it to the webserver for execution.
(i think you do need a webserver that will execute the script)

you should make a mini-tutorial showing how to use it, with a couple of examples , showing the actual javascript code that needs to be passed , the input and the outcome. we could have a snippet library submitted by the community that contains a collection of js code segments that can do many basic things best serviced by javascript.

1 Like

Yes, but that requires the web viewer which has its own problems like inability to run as local/packaged code.

The idea is for Thunkable to create a block or component that you can pass a JavaScript function and get the response in a way similar to API block but instead of passing a URL you just pass a JavaScript function.

This way we do not need to include the web viewer component and Thunkable would have lots and lots of generic functions in the JavaScript engine which solves lots of issues not only date related but many others.


Hi @muneer ,

I love the idea to have some sort of JS interpreter inside a block. It is maybe limited to core functions, because there is no way of using external libraries, or is it?

But if I understand correctly that kind of block does not exist. I think I can open an issue but do you think that this kind of block is easy to implement (maybe the whole ThunkableX-system runs on JS) or is it worthless to spend time on it because it’s too complicated?


It should be easy and it’s already part of React Native which is the underlying framework for Thunkable apps but I don’t know if they are willing to do it.

1 Like

So then I assume more than one way to use JS:

  • easiest way could be to just use some language parts like converting epoch time,
  • but what about using JS to interact with the blocks and components in ThunkableX? Or even build general purpose libraries, like having a repository of functions you could use in your whole app?

This sounds tempting. AFAIK every component has an ID like 123-456-789 or so, so you could programmatically have access to components like “set( “123-456-789”, “Text”, “Hello from a label!”);” with JS. That would open a new world, because then you could access all methods and functions even if they are not accessible within the blocks editor or the “simple/advanced design” screen.


If you take IFTTT for example, it allows setting standard conditions using its own list of preset conditions and it gives you the opportunity to code your own condition in JS as long as you give back true or false from your code.

If you take AppGyver, which is another development platform based on React Native, it has a JavaScript code block which you can use for a single command or a function you define with lots of lines of code. I have not used AppGyver since long but I wouldn’t think this option would be removed.

So in principal, yes it is doable.

we can keep hoping. using the webviewer to execute JS is a big pain point for me. I def dont like having to use that workaround.


Someone should create an official feature request on GitHub. Otherwise, things tend to get lost in the forums over time.


having a block that executes JS should already be a feature request i think @tatiang

I think i made one for that when i was working with thunkable. if not, it def needs to happen. it would reduce some pressure on thunkable staff to have to create EVERYTHING that we want to use. @conroy, if this isnt on the official internal feature request list, could you please add that? it’s an official request from your power thunkers. we want to execute inline JS scripts via a block that has inputs and an output.


I thought there would be an existing request but I didn’t find one.


Hi to everybody,

I just opened a new issue/feature request. Feel free to comment and vote on it:

Best, Michael


Thank you. This block is a necessity for all developers. Just imagine a one JS line will convert your number to HEX or vice versa. Another issue is the Unix date that you can manipulate with a single JS line.