Beta testers wanted

We may soon release an integration template that would allow users to create a database of time periods (days, weeks, months, quarters, years) as the next step in making managing date information in Fibery more user-friendly.

We’re interested in getting feedback from users on the first iteration before releasing to a larger audience.
If you’re interested in trying out what we have so far, here’s what you need to do:

  • Go to the integration tab in any space (I suggest creating a new space for experimenting)
  • Click on ‘Add custom app’
  • Type as the URL
  • Complete the configuration (see intro doc below)
  • Explore and have fun :slight_smile:
  • Give us your feedback :pray:


There’s a quick intro/explainer doc here, which should help you get started and provide inspiration for what you might use it for:

Note: this app will only function for the next couple of weeks. After that, attempts to install or sync will probably return an error. Please don’t use it for anything mission-critical. If/when we release the final version, it will not use the same url, so anything you have used this beta version for will be broken, and will need to be recreated :frowning_with_open_mouth:


Very nice @Chr1sG !
The data-structure looks very promising!
I created several of these structures myself in fibery - but it is a fickle friend and you always have to update it manually (or by script).

Good choice!

By enabling auto-sync on the app, you can have new time periods created in the future automatically.

Thank you for this. Testing it now.

wow, this is going to be amazing. Will try it out!

ah ha, so basicly we got date time database which I can use bullet journal method like review and plan for periodic right ?

1 Like

The app has no time elements to it - the lowest resolution is days

This is very interesting and I will try it out and report back. I am wondering if the source code for the app is going to be available as another custom integration example for devs to follow.

I do wonder though why this functionality isn’t being built into the “date” data type? Extending date type to make capturing other temporal concepts like quarter, month or year seems to be a much more robust solution that doesn’t require an external app, syncing or explicitly defining Q3 1992 beforehand. It also means that the field remains fundamentally a date and would (hopefully) maintain date functionality and would be able to be visualized on timelines while allowing things like binning on boards (which is a source of frustration for me right now).

If you create a date column in excel, when you apply a filter, it automatically generates a hierarchical structure of year, month, day. PowerBI also has the ability to format date types into quarters, months, …. I think dealing with this at a field/data type level might be a more sustainable approach long term.

While creating entities for years, quarters, months … certainly works, it does seem like a workaround rather than a fundamental solution.

1 Like

Overall, the end goal is to merge the functionality, so that there is a field type that has the best of both worlds:

  • a UI picker suited to the nature of time periods
  • variable granularity
  • functionally infinite ranges
  • support for time and dates (either and/or both)
  • available as an ‘axis’ for various views
  • semantic overloading
  • timezone/language configuration

But until that is possible (and there are technical reasons why it is not simple to overload the existing date field type with all this functionality) we figured some users would get benefit from this kind of solution.


Thanks for the explanation of the eventual goal. It is amazing and really comprehensive … and it makes me really happy to know fibery team is thinking along these lines. I hope some consideration would also be given to possible representation of fuzzy dates!

This integration is definitely very useful. Didn’t mean to come off as critical. Will definitely try and report back :blush:

Can you give some examples

Glad to know this is the long-term vision, but then will there be a migration path from the synced database approach? If not, why should I invest time/energy into making this undeniably more complicated/clunky approach work? I don’t mean to be harsh, maybe just a bit blunt. :wink:

1 Like

I have no idea how long it might be until the long-term vision is realised, and I have no idea if/how migration would take place.
There is a good chance that a migration could be semi-automatic, but an equally high chance that manual adjustments/corrections would also be needed.

Unless you have a specific use case that this current solution helps with significantly, then you probably shouldn’t :man_shrugging:
But my hope is, for some people, a solution similar to this beta offering is valuable enough that it is worth using until a long-term ideal is realised (whilst acknowledging that there may be migration challenges down the line if an even better solution is released).

I’ve got examples from my domain of work and what I’m grappling with for PKM. However, I do admit my examples likely do not align with the “ideal” fibery users who are in the technology/content creation arena. I discussed a few examples of fuzzy dates in an earlier post on Anytype:

In that post, I also talked about using conventions and what I’ve found to be the pitfalls:

I shared one approach that I’ve seen. Just cross-posting that in case it is helpful:

From a broader perspective, I think dealing with fuzzy / uncertain data is an important challenge for all data tools (especially when you talk about “knowledge”). However, I’m not expecting fibery to lead this or come up with a solution because it is likely not at all important to your customers (although once you start thinking about uncertainty in databases, you see it everywhere in all systems of record). But I try and keep raising it anytime there is a discussion about fundamental data types in the hope that eventually a conventional tool starts to tackle this challenge.

I’ll step down from my soapbox :grin:

1 Like

I assume that using date ranges like 1920-01-01 to 1929-12-31 for 1920s doesn’t work for you?

Yes! You got my attention now.
Any idea on timeline for TZ support, especially for rules.

With regard to ‘fuzzy dates’ it would certainly be possible to create a field that supported that, but it’s hard for me to understand how it would be different from a field that just used text.
In other words, how do you expect to manipulate or visualise a field that allowed both “Autumn 2013” and “the 1820‘s”?

I have to admit that I don’t have any particular answers on how best to do this (both from a data and UI perspective). The main reason I mentioned it hear is that I think there is greater value in encoding temporal information in a consistent way rather than just using plain text field. Within the application “date” fields carry specific semantic meaning (as temporal entities themselves), would have specific constraints & more specific UI, and allow fairly unique visualization (e.g. timelines, calendars and date wheels). Plain text fields would be very poor substitute.

I know the examples I provided above may not be all that interesting for majority of fibery users. However, I think uncertainty in the date field (and other data types like numbers) might still be valuable for core fibery uses (e.g. project management application). Examples include representing uncertainty in project cost estimates (estimate classes as +/- %) as well as project schedule (baseline schedule vs. worst-case). Almost all business applications mask uncertainty in values (or ask users to use comments or notes field to note them). Even when there are specific processes to assess & quantify the level of uncertainty, most data systems don’t have a way of storing this information and using it in future calculations, aggregation and reporting. It would be great if information systems would start to better represent reality by making uncertainty visible.

I think there are two independent facets here:

  • variable granularity
  • uncertainty

The former (being able to choose a week, or a month, or a quarter, etc.) is what is trying to be addressed with this integration

The latter (being able to choose a specific day/week/month knowing that you might be wrong) is not addressed, but is potentially solvable by using two or more fields, e.g. one field representing optimistic and one representing pessimistic, or perhaps a field representing best guess and another representing the magnitude of uncertainty.

I’ve been testing this out and finding it quite useful :slight_smile:

One of the things that would be really helpful is if periods could also have prior and next periods (of the same type) as well. So if you are using quarters, it would be great if you could easily access the previous or next quarter through formulas.

1 Like