But it is exactly what one puts in. For example:
- A user uses a date/time picker to pick a date.
- This date represents a unique moment in time (as all dates do)
- You save this in the database as type date (as you should).
Later, you retrieve this value. The value you retrieve is the exact same unique moment in time that the user specified.
That it is confusing that this object may look different to you when displayed in the browser is beside the point. The object you are looking at is the same object that was put in the database and describes the exact same moment in time. See?
BUT: What we often desire to do is what @arnold.smyth here desires to do:
The user selects some date/time. But we do not want the moment in time that the user has selected. What we want is a different moment in time… one that shares some characteristics of the date the user picked, but is not in fact the exact moment the user indicated to us.
(We imagine, as @arnold.smyth does, that we want to take that selected date – which might be something like February 13, 2019 at Noon in America/Los_Angeles – and “turn it into” February 13, 2019 at Noon in UTC. These are different moments in time and, hence, different date objects.
I have dubbed these things “parallel dates”. There’s probably some other name for them, but I like mine as I think it sounds quite intriguing!)
The issue with date pickers and the client is this: JavaScript (and, hence, all web browsers) will only construct a date in the client’s timezone. (This goes for servers running nodejs as well – in vanilla node, constructing a new date will make that date in the server’s timezone (which is usually UTC but does not have to be).
So, you have to be careful with what you’re snagging from a datepicker – or indeed from a date created server-side – you need to remember what it represents. (We wish that JS had not made the silly decision it did to treat dates this way – it might have been better if JS dates were always created in UTC, rather than having a UTC offset, but there’s nothing we can do about that.)
JavaScript dates are just difficult like that. (Hence, alternative solutions like moment.js. Moment objects are similar to JS dates, but are a bit more flexible, especially in the “moment-timezone” version.)
In vanilla Bubble, there is little we can do to work around this without totally adjusting your mindset and storing dates as string representations – but this is a lotta lotta work and you lose the ability to easily do things date-wise.
So: It would be nice if Bubble had a built-in function or operator to do this parallel date creation thing (which I why I’ve built a variety of things like this as plugins… those things are not available yet as server-side action plugins are a bit problematic right now in terms of speed).