Feature Requirement: Events about aardwolf HOT 11 OPEN

from aardwolf.

Just popping into this thread to mention that I'm like 100% down to help work on event stuff. I've done events before in Rust for a telegram bot

from aardwolf.

@deutrino, thanks for the warning and reminder that time-and-date-math is a PITA, and easy to muck up. I def think that storing time as UTC and also storing the intended zone is the best practice, along with using a lib like Luxon to handle the heavy lifting of managing the domain logic of timezones.

Didn't get around to writing up stories this weekend, next weekend 🤞

from aardwolf.

@BanjoFox Is it ok if I start stubbing out some user stories as issues…?

I just want to throw out the titles for now, scoped to reasonably small pieces, like, a user can create an event, or, an organizer can change an events time… Identifying the actors and actions should help us scope out what and how to build Aardwolf a bit better than Aaaah let's implement events.

from aardwolf.

Sure go ahead :)
If you want to put anything more detailed into them we can also add a new doc to the Hackers Guide to Aardwolf

Addendum:
Would it make more sense to do separate issues, or one EVENTS.md with tick-boxes?

from aardwolf.

🤔 I think that many small issues make sense, (spawning a new github issue is cheap) and then we can link to all the issues with ticky-boxes on this issue. This will be a big rock to move.

I don't quite get the Hacker's Guide… what is its intended purpose and audience?

from aardwolf.

It is supposed to be like a one-stop-shop for finding something to work on quickly. The associated files are supposed to act as "specifications" once the particular thing has been discussed, and agreed upon. Basically it is another way to present CONTRIBUTING.md (which is probably way out-of-date at this point).

Many small issues is okay, but might get harder to manage than one milestone. I would also hate to replicate that for -every- feature/function because then it -might- become more difficult to find things quickly in the issues list. :)

Have you done many issues->one-topic before? Do you have an example that I might be able to look at to get a better feel for it?

Addendum:
Both is okay XD

from aardwolf.

Will write out small issues this weekend.

from aardwolf.

Hi folks, just wanted to save y'all some time and mention, when figuring out how to store events in the database, you almost certainly want to store the times as "intended time:" a combination of the time and time zone for when the event is to occur. Then, when displaying the event, always render it using the Olson tzinfo database with the time zone in which the event is to be displayed.

This becomes necessary for e.g. users in countries with differing definitions of daylight savings time, or for when laws about daylight savings are changed in a country with ongoing recurring events, etc. It is even relevant solely within the United States, where some areas do not observe DST; further, the EU is again toying with the idea of ending summer time, and Russia made changes in recent years.

See also: https://www.w3.org/TR/timezone/

Source: spent over a year refactoring a web calendar app due to original decision to store events in UTC. Effort cost my employer well over $100K.

from aardwolf.

Another project dealing with events is GetTogether. They are looking for help with ActivityHub mastodon/mastodon#4179 (comment)

from aardwolf.

Yeah, UTC + Timezone is both the easiest (chrono::DateTime<chrono_tz::Tz> can't be used with Diesel, but chrono::DateTime<chrono::Utc> can) and also the way I did it for my event bot.

from aardwolf.