toText(Date) wrong timezone?

Using toText(Date) and Date has a time. e.g. 15:00 oclock set.

But it displays 14:00 oclock after toText(). Maybe wrong timezone?

Hi!
Yes, our bug. We don’t support timezones in formulas, sorry for that :frowning:
Will fix that! :muscle:

I believe Fibery uses UTC under the hood for all such calculations (probably because this is how JS normally does things and the clojurescript library they use wraps this? not 100% sure). I’m guessing you’re in UTC+1.

In my own formulas, I often want the Date of a given time, so use Time.start - Hours(5). Of course this only works for half the year because of daylight savings: you could solve this by editing the formulas or making a lookup to another variable so that this would only have to be changed in one place, not every formula. I haven’t bothered yet as I didn’t need the precision.

For you, you could solve with toText(Date + Hours(1)) for now (and Hours(2) in two weeks time! I guess in a few years the EU will get rid of daylight savings). This may not be exact enough for your needs in general, but could help.

Yes, the idea with shifting the hour is an idea. But you are right with the daytime problem twice a year.

Just wait for the fix. Maybe an own function dateToText(date,format,zone) is also an idea.

Yeah, timezones are generally a huge pain to deal with. Handling it by using simple hour offsets is setting yourself up for failure.

Like you said, if we could have whatever library that Fibery uses be exposed as a dateToText(...) and textToDate(...) formula that would be truly awesome.

1 Like

Probably/possibly related to this issue which is dates only

FYI:

Workarounds for timezones should be a short term and not a long term solution. It’s not reasonable to pitch Fibery as a remote work “second brain for teams” if my whole team needs to be in the same timezone.

1 Like

Here’s a thought experiment, and I’m curious to hear what people think.
Given that it is ideal if multiple people from different time zones can work in Fibery simultaneously, even editing the same entity simultaneously, how should a text field that contains a date-to-text conversion be shown to these different users?
The same for all users, or different?

Also, what about functions like Day() or Month() that are intended to extract the day or month of a date as a number?

1 Like

What I don’t get is why reinvent the wheel? I’m sure there will be extra effort to reengineer some internals, but there’s plenty of libraries that have figured out how to handle nearly all the edge cases for working with date, time, datetime, and timezones. For example: https://momentjs.com/ and Day.js · 2kB JavaScript date utility library

To answer your thought experiment:

dateToText(date) → date in UTC as string in default format

dateToText(date, tz) → date in tz as string in default format

dateToText(date, tz, fmt) → date in tz as string in the fmt format

For all the above the users time or timezone is irrelevant. For example,

dateToText(Now(), tz) → Now() converted to tz as string in default format

dateToText(someDatetime, tz) → someDatetime (stored as UTC serverside) converted to tz as string in default format

Text to date would function very similarly, but convert the output date depending on what the users set locale is.

textToDate(text, tz, strFmt) → date string is assumed to be in tz, saved to server as UTC, displayed on UI in users locale (or settings timezone)

1 Like

Since I’m not a sw guy with experience of these libraries, can you tell me, for something like dateToText(someDatetime, tz)
is it correct that the every user would see the same thing (so it will be ‘correct’ only for the chosen timezone)?
And does the result change as the clocks go back/forward in that timezone/location?

Yeah every user would see the time in the specified timezone with the appropriate time correction applied.

I suppose if you wanted to have the option where it was shown in the user’s local time you could make it happen when “local” was entered for tz. Example:

dateToText(someDatetime, "LOCAL") → someDatetime (stored as UTC serverside) converted to users local timezone (or settings timezone) as string in default format

1 Like