Hi there,
I am talking to an API that is used to determine how long a business process takes, given the process starting on a certain calendar day. To accomplish this, it takes an input date in YYYY-MM-DD format and returns a future date, again in YYYY-MM-DD format.
However, if I set the response field to the Bubble “date” data type, Bubble is trying to be too helpful. If the response field in the API is, for example:
complete_date: “2020-09-17”
if I mark that as a data element of type “date” and pass it to my DB, I get
“September 16, 2020 7:00 PM”
(to use one example of how one could render the date.)
It is almost as if Bubble is assuming the value coming back is a UTC representation, further assumes the lack of timestamp means midnight, and normalizes it to the local time zone I have set. I can see how that would be helpful - if I could control when it’s happening.
Is there a way I can defeat this auto-conversion, short of declaring the API response field as text and constructing my own date from parsing the string?
I should add that I know I can hack my way around this by simply adding date+1 to the date before storing it, but holy smoke what a goofy thing to have to do There must be a better way!
That behavior actually makes sense to me. I don’t think I’d want Bubble making any assumptions about a date coming from an external data source - especially since it has no timezone information associated with it. Defaulting to UTC seems like the sensible thing to do.
I’d suggest leaving it as a Text data type, parsing it, and then creating a new date and setting the year, month, date, hour, min, and sec explicitly. This should be straightforward now that Bubble has a :converted to number operator.
I agree, defaulting to UTC is a logical response, but I don’t think it’s the only logical response. ISO 8601 is a bit vague on how dates without times should be interpreted, but it does say times without timezones should generally be interpreted as local (server) time.
So I can see how the Bubble team might think treating everything unknown as UTC is the best of all potentially bad choices. But without explicitly stating this, it risks causing a lot of friction for a no-code developer… in a space (date/time management) which confuses many “true” developers!
That might make sense if there was an app-wide timezone setting, but AFAIK, there isn’t. Rather, there’s the notion of the user’s timezone, which is “the timezone as reported by the user’s web browser”.
As we both agree, though, it doesn’t make sense to assume that a date coming from an external data source is in the user’s time zone.
There must be a better way!
