Add timehashes to nip 52

[staab]

This does the same thing for timestamps as geohashes does for locations. There's likely a better way to accomplish the task, so feel suggestions on the code snippets and algorithm are welcome.

[fiatjaf]

Beautiful, elegant solution.

[staab]

Thinking through this more (thank you @arkin0x), there are degenerate scenarios in which long-duration events require many high-granularity hashes. This case can't be solved by only using lower-granularity hashes, because clients using high-granularity hashes in requests will no longer be able to find those events, and lower-granularity hashes force them to download and filter everything.

So I decided that the simplest thing to do is just pick a granularity and use it. As it happens one day is probably a pretty good balance for most use cases. Date-only events already have that information (and are timezone-agnostic anyway), so I only had to add the tag to datetime events.

@tyiu @arkin0x

[fiatjaf]

Beautiful, elegant solution.

[mikedilger]

So if you want all events happening this Friday, you can look them up with the "D" tag and it will include week-long events including Friday. Sounds good to me.

[staab]

Flotilla now publishes and filters using the D tag

[tyiu]

So if I wanted to get all the events for the next month, I would have to include ~30 D-tags in the subscription filter?

[1l0]

How about this

// Start timehashes
    ["T", "dy"],
    ["T", "dyj"],
    ["T", "dyju"],
    
// End timehashes
    ["D", "dy"],
    ["D", "dyj"],
    ["D", "dyju"],

[staab]

So if I wanted to get all the events for the next month, I would have to include ~30 D-tags in the subscription filter?

Yes. Not that bad if you compare it to the authors field.

How about this

This isn't terrible, but it doesn't allow targeting hashes during but not at the end or start of the event. You'd still have to scan backwards and forwards to get a complete list of events.