Forum Documentation Showcase Pricing Learn more

Date and Time data structuring

Hi everyone,
I’m currently structuring my data type and I want my users to be able to add multiple dates/times to each event they are adding.

But for when my customers see the event I would like them to see each seperate date with a list of times, which has been combined from the separate dates/times provided by the user before.

So what I would need is a workflow to find all the dates that are the same and merge their hours to give rise to a list of times, is this possible and how difficult do you guys think it would be?

Let me try and explain it a bit simpler, I will have a data field which is a list of dates. I want to seperate this list of dates into seperate dates with each having a list of times!

It sounds like what you are looking to do can be achieved through two things:

  • nested repeating groups
  • date/time :formatted as mm/dd/yyyy

Dates (or more precisely datetime objects) are basically agnostic numbers that represent a point in time. These dates can be expressed as text in your browser such as a date like 8/5/2019 or as a time 6:00PM or both 8/5/2019 6:00PM The user’s browser is in charge of what date and time will be displayed based on the local time zone.

Understanding that your dates are a points and also numbers is important because what you are asking for is to see if your dates are contained in between two date point numbers that make up a day (12:00:00.000AM 8/4/2019 EST and 11:59:59:999PM 8/4/2019 EST)

There are a few ways to what you want, such as trying to setup date ranges for each day and checking if your date point exists between them, but its likely overly cumbersome for your purposes.

A much simpler way to do what you want is to convert your dates to a mm/dd/yyyy texts on the page so you can work with them more easily as whole dates (your dates will remain saved as dates in the db or wherever).

Once you have a list of ‘whole date texts’ you can perform bubble operations and evaluations on those texts such :unique items which give you a list of unique date texts. Once you have that, you can run another search of all dates:converted to mm/dd/yyyy to see what matches.

Here is the an Example Application as well as the Editor

Also, don’t forget about timezones. Your dates are just agnostic numbers. The browser sets the date and the time of how dates are entered and displayed. If your user is entering 9:00PM in New York (EST), that would be grouped under the following day’s date for users looking at the same page in London (UTC)

1 Like

That was really interesting to see thanks alot for that Jon! This method is absolute genius with respect to its simplicity! I’m intrigued as to how you got the unique repeating groups type text working when the data is of type date.

[edit]: just saw the repeating group within a repeating group set up, makes sense! I’ll give it a go and get back to you!

I really like the method that you’ve shown, however would it be possible to get the times to stack up side by side and make them into buttons using groups? That’s the kind of functionality I am aiming for!

Would timezones be an issue if my website will only be starting in England? Do I have to set my timezone up? ahh haha why do dates have to be so confusing

Because dates are hard, unfortunately, and JavaScript date handling confuses the issue somewhat. I’ve written a lot about this and provide some pointers to past helpful writings on this topic.

The main thing to understand (and understanding this will alleviate much confusion about dates) is this:

A date object (a thing of the date data type) describes a unique point in time.

A “date” in programming is not what you are thinking of when we colloquially talk about dates. In human heads, a “date” is usually what would be better described as a “calendar day.” So normal humans think about “dates” and “times” as being different.

In programming, this is not the case. Dates are times. Date objects (and their derivatives) are how we represent time. So you will often see me refer to such objects as date/time objects and not simply as dates, because this point cannot be driven home enough.

Let’s say that you and I want to schedule a Slack call for this coming Thursday and I tell you that I am available over “lunchtime” where I am (which will be San Francisco) and would be happy to chat. In our heads, we are like “OK, Thursday August 8th will be the date of our call” and, furthermore, “the time of our call will be Noon, Keith’s time”.

But neither of these things separately – “August 8th” “Noon” – are dates.

“August 8th 2019 at Noon, Keith’s time” could be a date as it describes a unique point in time.

And this point in time is the same point in time for both of us, of course. However, you and I would write it down differently:

I’d jot down 8/8/19 at 12:00 PM (San Francisco time). You’d jot down 8/8/19 at 7:00 PM (UK time).

That moment in time is the same for both of us, but at that particular hour of the day I might be eating lunch and you might be starting to think about dinner.

This is the difference between date construction (or date parsing) and date formatting.

And this is why we have lots of nice options in Bubble for formatting dates. We don’t have quite as nice a collection of options for date construction (and date construction is conceptually a bit difficult for the reasons discussed above), which is why I build things like Calendar Grid Pro and have written a lot about how one can use libraries like moment and moment-timezone to help.

Anyway, here’s more prattle about dates that is actually good reading!:

2 Likes

Time is only a construct :exploding_head:
Because its 5 o’clock somewhere :tropical_drink:

In all seriousness. It is a nag for developers everywhere–not just bubble. I don’t think this is a technical issue as much as it is a conceptual one that requires a certain way of thinking about time that I don’t think is very intuitive for non-programmers / most humans.

Timezones are confusing even if you aren’t programming
I can’t tell you how many conference calls have been incorrectly scheduled because both parties thought they were scheduling to meet in their own timezone. We are inherently self-centered I guess :slight_smile:

Bookings are way different than just keeping track of time for an individual user.

You have to stop and think about what you want to do here because no software will truly know your intention and be able to do this for you, however bubble has done a lot to help with this. @keith has explained much of this.

I actually don’t think this is as complex as it seems–especially in your scenario. You already mentioned you don’t require multiple timezones. You’ve eliminated most of the confusion.

A bubble webpage gets the time zone from the device

If all users are in physically reside in same timezone and their clocks are set the same, then you are all reading and writing dates in the same timezone. I don’t think you’ll have a problem.

You’ll want to be careful though for edge cases though such as if you have users who are traveling on holiday to a different timezone and are logging into the site to book a date/time because they will be doing so in the local timezone where they reside.

Times will be shown in their local time by default. Time will also be entered from datepickers in local time, which means they’ll have to do the math in their head to enter the time correctly. i.e. if they want to book 3PM in London, but are physically in New York, they’ll need to enter 11:00AM to book the correct time. (Difficult)

You can force bubble to display times in a certain timezone no matter where the user is located.

I’d take a look at the full documentation for this.

Date pickers will set times in the local timezone. You can use an offset number between the local timezone and the timezone of truth and then take the output of the datepicker and adjust it back to the correct timezone.

How do you get the offset number?
The number will be different depending on where you are in the world and needs to be calculated by subtracting device’s local timezone from the timezone of truth. You should be able to calculate this offset number in bubble, but I’ve found that its hard to force the result in the expression.

I created a simple plugin called date and timezone tools to help with that and return the offset number for you. (There are others)

So then you take that offset number and do this as you save your time. If your offset number is calculated to be -4 such as NYC to London then as follows

  1. A user enter 3:00PM in the picker
  2. The picker outputs a time of 3:00PM NYC / (7:00PM London)
  3. You put an expression to adjust the time before saving to the db
    Booking Picker’s date:+hours:-4 (subtracting 4 hours)
  4. The new adjusted date is saved into the database as 11:00AM NYC / 3:00PM London

I’d make sure to let the user know this is what’s happening with a label near the picker ‘time in GMT’

Regarding dates as texts

Did you look at the editor link I sent?
Do a search for Event’s date returns a list of dates
Do a search for Event’s date:converted to ‘mm/dd/yyyy’ returns a list of texts

There are a few ways to skin this cat as far as implementation. What I did was one way.

1 Like

Not all of them, of course. :wink:

Thanks for this Keith, I’d seen your posts before and I was just about to start my learning after I sorted out this issue! Guess you beat me to it haha! This clears up what Jon was talking about with the date ranges for each day, but it does seem a bit excruciating for my purposes! @jon2 have you made use of the unique value method and do you have any comments on its reliability?

I will definitely need to make use of time ranges for recurring events, for example if my user says that their event will be happening every week for the next 4 weeks, I’d like my workflow to automatically add the subsequent dates. So for this example I would need an interval of +days: 7 and a date range. Maybe I could get a repeating group to generate the list of dates?

I can’t thank you guys enough!
So what you are saying is that the plugin will always be running and calculating the offset based of the current users timezone. Would I be able to define this dynamically so that whether they are in China or America, it can automatically know the offset ?

I had a look at the plugin and it says I can convert to UTC, is it limited to this or can I also convert to London? Haha funny how I’d never thought of this but you got me thinking what if my user is on holiday.

Sorry for so many questions, I want to get this all done tomorrow hopefully!

UTC is London time :slightly_smiling_face:

I’d say it is reliable. It grabs the local timezone code from the browser using the same JS that bubble or any site would. What it is doing is a very simple calculation of a - b

The timezone values it uses for that it uses for that calculation are pulled from whatever timezone settings are on the user’s device. As long as the user’s device time is configured correctly then it will work. A lot of technologies rely on the user’s system clock (including SSL encryption, etc) and so its generally acceptable to assume user time is ok to use. The alternative of using an API or geolocation to determine an offset I would assume to be far more unreliable.

In your situation, I’d think carefully about when you are using a date range vs just multiple single dates

In bubble, a date range is simply a pair of dates [ date begin , date end ]. You can think of it as a list of dates that contains only 2 items. Bubble has some built-in features that can make working with date ranges somewhat easier in certain circumstances. In other circumstances, I’ve found it more confusing/difficult to work with date ranges.

You’ll want to play around with date / time expressions on a scratch page and read the bubble docs to make sure what will work for you committing to an app design.

You can essentially do the same with separate date fields in the db such as event date start and event date stop for each event entry in the db.

I’m waiting for someone to tell me I’m wrong for saying this, but that has seemed to bring the most clarity and work the best for me.

the follow up to this

This actually may not be correct. Don’t forget Daylight Savings. Here is a link to London’s timezone info. Besides being geographically-related, timezones are also a political designation (see:time is a construct). The U.S. the state of Indiana has different counties that each have their own timezone. I wouldn’t freak out about the intricacies of things like this this, just use the users local time on their machine and trust they know how to read a clock and know if its accurate.

What to do about all of this?
I’d consider focusing on building your application architecture first (understanding how you’ll be storing your dates in the db, etc), before focusing on the edge-case stuff like initializing dates/times with timezones–especially if your users are all expected to be in the London timezone.

This seems like very edge-case scenario for your user. A simplified UX solution might be easiest way to tackle this vs being paranoid about converting timezones.

Perhaps a conditional text next to the date picker that shows only if the user’s timezone is different than London.

The conditional:


The display text:

This involves no messing around with shifting dates and All without a plugin. :slight_smile:

Again, here is the an Example Application . Try playing around with the timezone in your computer settings to see the conditional in action!
The Editor

Hi Jon, luckily I found this one made by Dave Repeat date input calendar works perfectly for my scenario!

In regard to the timezone
I have a lot of workflows for adding dates/times, if I was to use the plugin or even just bubble as it converts everything into UTC that would mean every date I add would be “tampered” data, no?
because then I would have to consider UTC and BST (UTC+1HR) for the 6 months of a year.

To be honest I think this is unneccessarily complicated, what if I just made a seperate dropdown for the time and stored it as a text? That way bubble wouldn’t be able to interfere? Regardless of what the users timezone is, this method would work, even if the website scales up to multiple regions?

What do you think of this?

1 Like

That is what I have done.

Save the time and dates as texts.

You need to do this at the same moment the date is saved. And if you need to later modify the date its quite troublesome.

UTC is NOT London time. UTC is devoid of time zones (EDIT: time standards). It is “Universal Coordinated Time”. I don’t know (and do not care) if London observes DST, but IF THEY DO, UTC erases this.

UTC (“Zulu time”) is an artificial time zone.

1 Like

@momam1997
Whatever you do, be consistent. Bubble really encourages displaying and entering with local time.

  • If you are saving in UTC, then make sure you are forcing your displayed times in your app to UTC (hint:bubble will always default to the users local timezone).
  • Make sure that all date pickers are saving dates to UTC.
  • If you are working with the bubble data tab and entering time into the Db ‘directly’ remember that it will default to your local time.

In my own application I have users across multiple time zones who are all scheduling in a single timezone. I also get whole dates from an API in text format YYYYMMDD and I need a server-side plugin to convert it and work with dates. The server uses UTC and Keeping everything in UTC makes perfect sense for my use-case. I can’t say if that’s true for you. If you plan to manipulate dates via server-side API workflows or via external APIs, I’d certainly consider it.

I ended up going with a javascript that gets the offset, do u think this is less reliable than API? I will add more about what i did later, but im at work now lol

BTW, London observes DST. During this period, they are on timezone BST (British Summer Time).

Aside: I really hate the nomenclature that is currently standard around timezones. It’s true that technically things like PDT (Pacific Daylight Time), PST (Pacific Standard Time), the aforementioned BST, are “time zones”, but to my mind, these would be better called “Time Standards” as they are cultural artifacts of standardization of time representations.

As another example: UTC is not a time zone, it is a time standard devoid of adjustments. It happens to coincide with GMT, but UTC is not a place on the globe. Similarly, things that denote adjustments (PDT, PST, EDT, EST) should also be “time standards.”

At any rate, the IANA Timezone ID (like America/Los_Angeles) is the thing we are really interested in and we depend on libraries and APIs (powered by the IANA Timezone database) to sort out the stupid regulatory part of time representation.

1 Like

Additionally, @mokam1997, while I had some other input for you regarding representing recurring things, it’s rather long and involved. But you might also be interested in this:

Live Bubbling with Keith: Let's Talk About Dates - Explaining the Basics of Dates in Bubble

1 Like

Thanks alot for that Keith, looks good! I’ll give it a good watch after work!

Currently i think i’ve solved the repeating dates and timezone issue seperately.

My workflow keeps everything as it is if the user is in London time, if not when the user adds a date it saves as date+regionaloffset(seconds)+daylightsavingoffset(seconds)

However, i think when i try to use the the same value for a user adding in london it takes 1 hour off haha so it doesnt work!

But i’ve tested it for various other timezones and it seems to be working fine!