Date Frequency Control

I’d love if there were some sort of control for date frequency, similar to the date range control.

Google Calendar has this feature, which gives you options for how frequently an event repeats:

It would be really cool if there were something similar in Coda.

Example of time it could be used:
My team would like to control how frequently a doc sends them an update. One person wants it to happen every third Thursday of the month, the other wants it every Monday. I can hardcode that, but there’s no easy way for them to be able to customize it if they change their mind.

Oh yeah - This would be phenomenal.

I once made an attempt at something similar (see doc below), but it wasn’t customizable per user. It was also a pretty wacko amount of formulas just for a few options on the users end - but it did give some quick/easy ways to customize notifications for users without touching code.

I know what follows isn’t perfect, but it did the job to a minimal level!

1 Like

I think I know what I’m building on a Patron livestream tonight :slight_smile:


Yeah! It’s a surprisingly incompressible problem…

@Paul_Danyliuk, instead of making a date frequency control in your livestream, could you make a new date system? The romans did a bad job

Treat the year as if it’s 364 days long. That means 52 weeks of 7 days each. 13 months of 28 days each and two hemiyears . The extra day (or two days, in the case of a leap year) is tacked onto the end, but it’s not all that consequential given that New Years day is often a holiday. In the case of a leap year, make it two days of holiday. Just make it social convention to completely ignore those days for most work purposes.

That would make all date time calculations so much easier. We could make a pack for this so that it converts easily between simple time and Gregorian time, but then all our formulas could be written in simple time.

Imagine how much easier subscriptions would be. You pay x amount per simple month, and by the way, each month has the same number of days!

  • Want to know the day when the next month starts? Easy: (Floor(Today().DayNumber() / 28) + 1) * 28
  • Want to go to the same day of the month, two months from now: Today().DayNumber() + (28*2)
    It’s also much easy to answer cost questions that way.

“We’re switching to simple time for your upcoming bill. That means instead of paying $780 per month, 12 times a year, you’ll pay $720 per simple month, which happen 13 times per year.”

I wish I could, lol :grin:

And you forgot the timezones. Especially the historic timezone data. I wish I could erase those and we all would just use Swatch Internet time.

1 Like

Obviously, everyone should switch to UTC. It’s easy.

You can just say, “Let’s meet at 15” and you never have to convert between timezones.

Then if you want to communicate how early or late it is for you, use longitude to define new, simple timezones, and then you’ll just communicate the percent through the local day that you are.

“This is 40% for me.” That’s not bad. But “This is 10%” or “90%” is really early and pretty late.

0% midnight
10% 2:24 am
20% 4:48 am
30% 7:12 am
40% 9:36 am
50% 12 pm
60% 2:24 pm
70% 4:48 pm
80% 7:12 pm
90% 9:36 pm
100% midnight

“create your own calendar”

we did that

at our little consultancy we ALWAYS use iso (WW.D) for project and task dates.

once our clients get into this they love it. it makes mental arithmetic with dates trivial.

“its now w49.1 and the deadline is w53.4, so how many weekdays is that? (5×(53-49)+4-1=23)
how many weekends in that span? (53-49=4)
lets have a meetup at the half-way point, when is that? (4/2+49=w51)”

(try working those out in your head using gregorean calender dates!)

and it makes repeating dates easy to specify within the weekly framework - all our sprint durations are interger weeks

the week turns out to be the real heartbeat of business

even accountants use week numbers in preference to months where possible

most project management tools and calendars understand iso week numbers. though microsoft has its own system (typical)

as for utc…
we NEVER use a.m or p.m
we ALWAYS 24 hour plus time zone
anytbing else is just not professional
imagine airline pilots or train drivers getting ambigious with specifying times (boom!)

as for weeks starting on SUNDAY?
do NOT get me started!

just a thought :wink:


Great input @Xyzor_Max , :star::star::star:

As long as you can get the buy in from your business partners, this is the way to go.

Several years ago, working for a Swedish multinational having the power to enforce, this was the way we worked and with external business partners.

Just unbelievable easy from many perspectives and no confusion. Unbelievable that it’s not a common approach.

1 Like