fix(i18n): compatible with timestamp in milliseconds or null values #1775
Conversation
Justineo
requested review from
adamdehaven,
ValeryG,
jillztom and
a team
as code owners
packages/core/i18n/src/i18n.ts
Outdated
| const invalidDate = 'Invalid Date' | ||
| if (!timestamp) { | ||
| return invalidDate | ||
| return '-' |
There was a problem hiding this comment.
not saying this is wrong change, but would some places where user expects to see Invalid Date and now sees - be "broken" or "changed without the user's content" ? Also are we sure there are no tests that expects Invalid Date ?
Seems that the change is not related to shameful normalize and can be excluded from this PR, unless it's absolutely needed?
There was a problem hiding this comment.
I can revert this change, as it was intended to handle potential null values returned by backend APIs, and we are already providing the correct fallback value (use created_at if updated_at is null). I’m just curious to understand if there are any scenarios in our current design where we might expect to see Invalid Date.
There was a problem hiding this comment.
I don't see this string anywhere in the tests. So looks like safe change. If someone complains we just file JIRA and fix :)
There was a problem hiding this comment.
Sounds good. Can you stamp this one?
packages/core/i18n/src/i18n.ts
Outdated
| const invalidDate = 'Invalid Date' | ||
| if (!timestamp) { | ||
| return invalidDate | ||
| return '-' |
There was a problem hiding this comment.
| return '-' | |
| return '—' |
Can we use emdash instead please?
There was a problem hiding this comment.
I think I should just remove this. We are already handling null before this.
Justineo
force-pushed
the
fix/normalize-timestamp
branch
from
b94d828
to
ea9873e
Compare
| @@ -52,6 +52,19 @@ export const createI18n = <MessageSource extends Record<string, any>> | |||
| const { $t, ...otherProps } = intlOriginal | |||
| const intl = otherProps | |||
|
|
|||
| /** | |||
| * Shamefully normalize a timestamp to be in seconds as some APIs are returning timestamps in milliseconds | |||
| * TODO: Remove this function once all timestamps are normalized from the backend | |||
There was a problem hiding this comment.
Ticket for the backend: MA-3412
|
I've updated the code and no longer handles |
Preview components from this PR in consuming applicationIn consuming application project install preview versions of shared packages generated by this PR: |
Summary
The filter API is returning timestamps in milliseconds instead of seconds and
nullasupdated_atvalues for those weren't modified since created. The issue affects both filtered services and routes.Before:
After: