Resolve date discrepancy and remove need for tinytime dependency #1811
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR will…
resolve a date mismatch issue caused by
tinytime
not preserving timezone informationI noticed this when sharing the job app links on Twitter. I'm not sure if this occurs in every time zone, or if I'm only seeing it because I'm currently traveling in Los Angeles.
refactor and improve the
formatDate
functionrefactor and improve the
formatDate
function to build upon built-in APIsMost of what tinytime was being used for can be offloaded to
Intl.DateTimeFormat
, which is natively supported with great browser support.The only regression/difference I noticed was that in the case of the job applications usage of
formatDate
, you lose the ordinal day number (e.g.4
now instead of4th
). If that's an important difference and you really want the ordinal number there, I have a helper that essentially shims'ordinal
support for the day number. It would just be a deviation from the built-inIntl.DateTimeFormatOptions
type, so if you do any TS type checking, you'll want to account for that as well.removes the—now unused—the
tinytime
dependency