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
[Feature] Extend since
with abbreviated
#311
Conversation
since
with abbreviation
since
with abbreviated
Not sure why builds are failing -- seems environmental? |
Also an open question - spaces or no spaces? No spaces fits the theme better but it's slightly easier to remove spaces than add them. |
oh hey, this is cool. Is this the same as this? Your scheme, it's human-readable purposes right? Maybe we could do both. |
I didn't know that spec existed but it makes sense that it does. Yeah I guess this is some middle ground between spec and readability? If that middle ground is the goal (which I think it should be), maybe we do default to spaces? What do you think? |
Honestly either way someone somewhere's going to be inconvenienced so I'm at a loss. |
yep. i agree. I'll merge it and take a look. |
any thoughts on this? export interface Since {
diff: Diff
rounded: string
qualified: string
precise: string
abbreviated: string[]
iso: string
direction: 'past' | 'present' | 'future'
} { ...,
precise: '10 hours, 59 minutes ago',
abbreviated: ['10h', '59m', '10s'],
iso: 'P0Y0M0DT10H59M10S',
direction: 'past'
} the iso format doesn't go negative either - so it's pretty similar to your scheme. |
ha love using an array, very elegant sidestep. Good call on adding directionality too, otherwise it'd have to be inferred from another value. lgtm 👍 |
Oh what does this mean for |
I would go with ['0s']. That should keep it consistent in usage and it's still friendly enough for users. |
This pr extends the return of the
since
method with a new string propabbreviated
following the pattern1y2m3d4m5s
. I've found myself doing it enough times that I think it's a worthy addition.I realize that
m
for month and minute can be ambiguous, but I think most if not all of the time it should be contextually apparent.abbreviated
also deviates from the other properties in that it is always positive regardless of relativity, it's open to discussion but I think it makes sense in context.I've extended all tests and ensured they pass, and updated the
Since
type. I didn't update the readme because it already only covers two of the existing returns types.