Dates and time

This section covers elements that accepts dates and time as user input

Date and time elements allow your users to specify a date, a time or both in different ways. Whether you want to save a user's birthday, filter search results or accept bookings in a specific time zone, Bubble offers multiple tools to set it up in a user-friendly way.

Designing a UX that handles dates and time opens up for a wide range of different scenarios. While Bubble's built-in tools provide a variety of features, there are also a lot of plugins that offer even more customization. Check out our plugin store to learn more.

How Bubble handles dates and time

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

  • 01/31/2050 - 01:00 pm

  • 31/1/2050 - 13:00

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:

  • 2527264800

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:

  1. A user in New York saves the datetime 01/31/2050 - 01:00 pm The offset from UTC is -05:00 or -18000 seconds

  2. 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.

Date/time picker

The date/time picker lets your users pick a date and a time from a visual calendar. It can also be set up to only pick a date, in which case the field to the right in the animation below will be hidden.

If you set up the element to only ask for a date, the date will be saved at 12 am (00:00) on the chosen date in the . If you have selected a different time zone in the , the date will be saved at 12 am (00:00) in that time zone.

You can set a minimum and maximum date as well as a minimum and maximum time of day, and you can set the interval for the time picker (which is 30 minutes by default).

Field type returned: date

Video lessons

Input element

The input element is mainly used for text input, but can be set up to expect a date instead. In this case the user will not see a calendar or time picker, but will instead be able to type the date directly. Note that the input element supports dates but not time. It can be set up to format the date in:

  • US format (mm/dd/yyyy)

  • European format (dd/mm/yyyy)

Field type returned: date

Last updated