Not by duration exactly, but by timeframe. But I think that's what you meant.
The alternative would be potentially to just list the dates the event falls on in YYYY-MM-DD format, but that's basically just a time hash, and introduces the question of timezones. Another alternative would be to have queries like since/until on tags, but that seems unlikely to get adopted at a meaningful rate.
The language about duration here made it confusing
I suggest you mention that timehash is a timeframe and provide an external reference like you did for geohashes. I wasn't familiar with timehashes until this so I had no context for the NIP.
The part I don't like about it is on the client side it's super clunky to query for this stuff since you need to publish a lot of timehash tags and query a lot of timehash tags. It just feels like a hack. But it will probably be a better UX than geohash stuff since it is only 1D and I can't think of a better way to do it! So nice work!
You're right, the duration language is my fault, I'll change that. You haven't heard of timehashes because I invented them 😉
It's actually not too bad to either publish or query these, since if all three recommended levels of granularity exist as tags you can choose which to target with a filter depending on how wide your window is. The degenerate edge case is of course events that last for a long time, since you have to enumerate approximately every hour. I'm not quite sure what to do in that situation.
