-
Notifications
You must be signed in to change notification settings - Fork 1
feat: cleanup & simplify timestamp handling #54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I liked |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good overall, happy to take a closer a look at any specifics if you want a line-by-line
I went through a few different iterations to find a specification that worked well. What I ended up with wasn't too far from where we started, so I opted for backcompat with warnings for changes to how we're handling relative timestamps.
_AnyTimeDomain
: all time domains that we allowThis is value that should be used in the high-level client. It allows for basic literals + strongly typed values.
_LiteralAbsolute
valuesThese are the values we expect many users will use - simple, literal strings.
TypedTimeDomain
valuesThese are the strongly typed time domains. These include additional parameterized types, like
Relative
andCustom
.TypedTimeDomain
constantsThese are equivalent to the string representations.
_LiteralRelativeDeprecated
valuesUsage of these values is deprecated and will send a
UserWarning
to usenm.ts.Relative()
. These are deprecated since we want the users to explicitly add the start time. However these are currently in-use, so we're emitting a warning but still allowing them for now.The warning raised will look like:
Exploration
winner: mix of strings + types, but advertise with constants
current: mix of strings + types: relative offsets not supported yet, would need to create a new type for it
strongly typed: types and docstrings are extremely clear, allows more flexibility per-type
flexible factory function: multiple behaviors depending on how you call it; difficult to document but easy to read
mix of strings + types, but advertise with singletons
factory functions for each type - pretty chill but wordier than strings
singletons (with transforming class methods) - too magic, custom() behaves differently