Forum Documentation Showcase Pricing Learn more

[New Plugin] UNIX Converter


Convert local time, UTC, Time Zones & a whole lot more into and out of UNIX time.
Explore the possibility’s of an easy to access multi time environment.
No API keys, just install and enjoy.

for those of you that don’t know what UNIX time is - the easy explanation is imagine if time started at 1st Jan, 1970 at 00:00:00 o’clock. then time was just a second counter from then. so at the time im writing this UNIX time is 1494970738 UTC.


Open Block for Converting Timezones
Add timezone to date time picker

What format should the output field be?

I’m having trouble converting a timestamp to a date in the final step of my timezone conversion debacle…

Stamp to local date says it is a text not a date
Stamp to utc gives empty result
Date to unix with the unix as the time parameter also results in empty.

I need Unix to date but even if I take the default parameter in your setup for stamp to utc > utc’s date (as date field) is empty:

Output cannot be a date field?



Try this, when you get to the reference that ultimately is where the needed date is written to the db have it add like this -

Current date/time changeyearsto 1970, changemonthsto 1, changedateto 1, changehoursto 0, changeminutesto 0, change secondsto 0, +(seconds): YOURUNIX STAMP.

Im sure you see where im going there but incase your not sure, we have made your time and date 01/01/1970 00:00:00. Then we have added the unix stamp to it as seconds. Because unix is seconds since that date your result should be a correctly configured date and time in the correct thing type.


Get the GMT offset for a Timezone

It seems hours are not changed to 0:


But minutes are:

I actually see this was raised before, but can’t tell how it was resolved. Maybe its a bug in my instance…



thats is fine, 0 is midnight and that is what we want. now go ahead and +seconds and use the unix stamp as the seconds and let me know what time comes out…



here is what i mean.





Thanks. It didnt work because I was referencing the stored DB result and not the converted result before getting stored in the DB so it kept giving an offset. Also, the conversion process takes to long for the date to be stored correctly, so this is not a great solution.

Finally, the main issue remains with this method: no matter in what timezone you store the date, the date output will always be showsn in the current browser’s time. So the only way to fix this is to have a formatted date which can only be a text. Unless I miss something.



is the stored db unix stamp a number? as for convert time, cant you add an only when result of convert isnt empty to the create action?.

main issue: looking at my previous post, are you saying the time i end with is my browsers time? because its not, its zulu time. meaning no matter where the user is in the world if you do the above action the result will be correct for them because you start with the 1970 base figure and add that geolocations current unix stamp to it. so if i wanted to change the result in my example to my time i would just add 9.5hrs x 60 (now its minutes) x 60 (now its 9.5hrs in seconds) then add it or have obtained the unix stamp of my locations current time using the api’s as you are…

1 Like


What I’m trying to do is a little different from the issues I’ve read before that require timezone conversion, I think.

Basically I have a thing that is set in an arbitrary timezone, the thing has multiple locations, but the date and time should always be local. A static timezone would do because it will always be clear what that local timezone would be.

The problem is that people enter a date/time through a date picker in their browser’s timezone which gets stored as UTC/Zulu in the DB.

I could convert it to real UTC before storing but the problem is that the date picker shows the current user’s local timezone and when they finish entering it will show UTC so unless they are in a UTC timezone, it will show off from what they entered.

So basically the situation is such:

Thing is in timezone X

User A sitting in Timezone Y updates a field in Thing through date picker and enters 21 September @ 9:00am

Things date field gets updated to 21 September @ 9:00am

User B sitting in Timezone X checks Thing’s date field and sees 21 September @ 9:00am

btw, sorry for hijacking your plugin thread!



Sorry to keep spamming your thread. I don’t want to start anothe while there is so much in different topics, but I’m a bit stuck at the moment so hopefully @romanmg @sridharan.s or @jarrad can help me untangle this mess.

As explained above I need to have users in different timezones enter a time and date through a date picker that shows up exactly as they entered it while other users in different timezones see the same date and time.

This is what works:
User thing has field ‘timezone’ (example: User X @ UTC+2)

Date picker stores a date field as is. (21 September 9:00pm)

TimezoneDB converts from current user’s ‘timezone’ to UTC :

> fromAbbreviation: 
> fromTimestamp: 
> 1506027600
> toZoneName: 
> Europe/London
> toAbbreviation: 
> toTimestamp: 
> 1506020400
> offset: 
> -7200 

Another field calculates the offset from UTC to current user’s ‘timezone’

Output field serves:
1970-1-1 00:00 + UTC timestamp + offset timestamp

This works when the user changes timezones. The time stays the same but the real problem lies with the browser/system time.
When I change the time on my computer, every date field on the page automatically displays UTC in the browser’s timezone.

@kramwe 's blockspring block indeed converts a time to a specified timezone but the entry and output are different so that is confusing to the user.

As I said, little stuck here :confused:



I don’t know that I understand your challenge and am in a bit of a rush, but hoping this will help:

  • Could you collect data from users and use the block to convert it to, say, UTC time
  • Then store the selected timezone in your database as well
  • Then, when displaying it back to users use those two pieces of information to covert it to either 1) the selected timezone or 2) the current user’s timezone, depending on which of the view approaches to displaying time you want to take.

Best of luck!

1 Like


Thanks for the reply.

If this is indeed the way to go, (which I had come to in an earlier version, and this actually works), then I find it pretty complicated for what it needs to do. Unless someone can tell me that it can be less complicated:

enter date in date picker
enter time zone (this can be prepopulated)

goes into:

field blockspring converter
users timezone: UTC
event timezone: timezone’s value
start time: datepicker’s value, formatted

either then it can be brought back into a date picker by converting to unix timestamp or displayed in a regular text input/text formatted with a dynamic timezone.

My users wont like this I’m afraid since it will be pretty slow to update :frowning:

If only there was a text field that could behave as a date field. A static date field so to speak.

In any case, thanks for helping me get my thoughts straightened :smiley:



hold on im building an example… using no api’s and pretty simple.

1 Like


ok, so you will see alot of numbers like 8, 9.5, 43200 and so on… these are all for the most part because we have 2 “users” on the same page to demo… in actual implementation these would be current users offset, current cells offset -, current cells offset + and so on… so at first this might look a bit complex but i assure you your finished product done this way will be a lot less going on, need no external services and result in date types on both ends… oh and the input up the top is the offset hrs in seconds…





Diving right in!




may the force be with you.



Can’t seem to open the editor…



bloody bubble, when that happens you will notice the url is

to fix, remove the amp; eg.

.i should stop being lazy and just start doing this, Editor

1 Like


Why are Input minus cals bb and Input minus cals aa different? Shouldnt they be the same?

I’ll rebuild this in my app tomorrow so i can change the user offset as just changing system timezones will not be sufficient in your example.

Thanks again for taking the time to set this up!



no worries, the offset side of things i assumed i could be slack as you would probly have a solution already… ad for bb and aa i will look and let you know…