Before starting to work with dates and time in Bubble, it's useful to know the basic facts about how this data is handled by Bubble.
How dates and time is saved
When you look at a date and time in Bubble, it's formatted in an easily readable format such as
In your app's database on the other hand, dates and times are saved in a different way. They are stored in a format called Unix time (sometimes called epoch time).
The time in the example above would be stored like this if you are in New York City:
Unix time is a way for computers store dates and times as a numerical value. Instead of storing it as human-readable strings (like in the upper examples), Unix time represents them as the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC.
This is not a Bubble-specific design choice, but is used across most computer systems, making it a universally recognized standard to store and exchange date and time information.
The advantage of using Unix time is that it allows a computer to perform simple arithmetic operations with dates and times, such as comparing or sorting them, because they are represented as a single numerical value.
Additionally, Unix time is independent of any specific time zone or calendar, making it an absolute value. The time above is 2527264800 wherever you are in the world, but the humanly-readable format of 01/31/2050 - 01:00 pm would change depending on which time zone you are in.
Two more points arise as a natural consequence of this design:
Both a date and a time is always saved
Since all dates and times are stored as a numerical value representing seconds, it follows that this value never represents only a date or only a time: both are always saved. Whenever you save just a date in Bubble, it saves that date at 12 am (00:00) on that date in the provided time zone.
You are not saving a time zone
Whenever you provide a date and time to store in the Bubble database, you are not storing a time zone along with it. Keep in mind: time zones are not actual values – they are just the formatting of a unix time value into a readable text that matches the requested time zone. Still, that doesn't mean you don't need to take time zones into account.
Let's look at an example to illustrate:
A user in New York saves the datetime 01/31/2050 - 01:00 pm
The offset from UTC is -05:00 or -18000 seconds
A user in Sydney saves the same datetime 01/31/2050 - 01:00 pm
The offset from UTC is +11:00 or 39600 seconds
As the example shows, while they are providing the same date and time respective to their local time zone, Australia time is 16:00 hours ahead of New York.
The lesson from this is that Bubble doesn't actually save the time zone, but the logic above would lead Bubble to store two different Unix time values:
In New York (IST) the Unix time is 2527264800 seconds
In Sydney (AEST), the Unix time is 2527207200 seconds.
Knowing the the time difference is 16 hours, the two unix time numbers should be 57600 seconds apart – which they are.
How do I keep track of this complex system?
In most regards, you don't need to. Time and dates are complicated to work with because of time zones, leap years, Daylight Savings Time and other inconsistensies, but Bubble takes care of all of these calculations for you.
The purpose of this infobox is to give a general understanding of how time and dates are stored and processed as this can make it easier to use Bubble's tools efficiently.
A caution when importing datetime data
Dates are stored in the Bubble database in an epoch or UNIX time format.
This format looks at the number of seconds that have elapsed since midnight UTC on Jan 1, 1970, which can result in some inconsistency when dealing with dates that are very far in the past or in the future from 1970. Owing to the instability of the epoch time format in handling dates significantly distant from the epoch, there can be an irregular offset associated with the date.
As a result, importing and re-exporting (or vice versa) these types of dates can result in slightly offset values.
At present, the only alternative to bypass this issue is to store dates as "text" fields. However, we are actively exploring potential enhancements to time zone handling, which could alleviate this issue in the future.
