Add TimeFieldIndex

[hackerwins]

My team is using memdb with a time.Time field. In my view, time.Time is a type that can be used in general.

I don't know if this is a good way to index the time.Time field, but this PR adds a TimeFieldIndex to make it easy to index time.Time.

Notes for reviewer:

Adding a Time field to TestObject causes panic from quick.Check. So I added a separate object, TestObjectWithTime.
golang/go#27017

[hashicorp-cla]

All committers have signed the CLA.

[kisunji]

Hi @hackerwins, thank you for this PR.

I think that indexing time.Time should be implemented by clients and not the library because requirements may differ (e.g. datetime precision or memory constraints for indices).

Right now I don't see a strong reason to add it to our library but will leave this PR open as a reference or discussion point for others.

[hackerwins]

@kisunji Thanks for your review.

In my view, I don't think it will cause memory problems much since time.Time can be expressed as 12 bytes(similar to indexing 12 character strings). And If the library does not support TimeFieldIndex, client has to change time.Time fields to byte slices and index it and this is a bit cumbersome.

But it may be just me for now, so I'm curious what other people think.

[radeksimko]

I understand the concerns mentioned, I'll just say that we have a use case for this exact implementation (full precision), primarily for sorting. Specifically we track changes to modules in Terraform LS, each with a timestamp and when processing these changes we want to iterate from oldest to newest record. We could also just use incrementing uint counter, but we already use the timestamp to batch changes within a certain timespan, so it seems better to reuse that field than add a new one.

I didn't try to compare the memory usage of time.Time field indexed vs extra uint field indexed. Given the anticipated amount of records at any given time though I doubt it would make a difference for us.

I'd be curious about the other use cases which involve lookups and/or reduced precision for memory savings. Relatedly I wonder if the precision could be somehow configurable, similar to how letter casing is configurable for StringFieldIndex? 🤔