AAE-43749 Added date formatting according to locale#11769
AAE-43749 Added date formatting according to locale#11769tomaszhanaj wants to merge 2 commits intodevelopfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Updates TimeAgoPipe to format “older than 7 days” timestamps using Angular DatePipe’s locale-aware 'short' format instead of a fixed date-time pattern, aligning absolute date output with the active locale.
Changes:
- Remove configurable
defaultDateTimeFormatusage inTimeAgoPipeand switch absolute formatting toDatePipe(...).transform(..., 'short'). - Expand unit tests to cover locale-aware absolute formatting and additional relative/locale behaviors.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
lib/core/src/lib/pipes/time-ago.pipe.ts |
Switches absolute date formatting to locale-aware 'short' and removes app-config-based format selection. |
lib/core/src/lib/pipes/time-ago.pipe.spec.ts |
Adds/updates tests for locale-aware formatting and relative/absolute behavior, including clock mocking and locale registration. |
| if (diff > 7) { | ||
| const datePipe: DatePipe = new DatePipe(actualLocale); | ||
| return datePipe.transform(value, this.defaultDateTimeFormat); | ||
| return datePipe.transform(value, 'short', null, actualLocale); |
There was a problem hiding this comment.
This change removes support for the configurable dateValues.defaultDateTimeFormat (defined in app config schema) and hard-codes the output to DatePipe's 'short'. This is a behavioral/config compatibility change for anyone relying on dateValues.defaultDateTimeFormat to control the absolute (older-than-7-days) formatting. Consider keeping the app-config override as the primary format and falling back to 'short' (or the previous default) when not configured, while still passing the resolved locale to DatePipe.
There was a problem hiding this comment.
With this default format locale is not applied.
| if (diff > 7) { | ||
| const datePipe: DatePipe = new DatePipe(actualLocale); | ||
| return datePipe.transform(value, this.defaultDateTimeFormat); | ||
| return datePipe.transform(value, 'short', null, actualLocale); |
There was a problem hiding this comment.
DatePipe.transform(...) can return null (e.g., if an invalid date slips through), but this pipe otherwise returns strings. To avoid propagating null into templates/consumers, coalesce the result to an empty string (or a defined fallback) before returning.
| return datePipe.transform(value, 'short', null, actualLocale); | |
| return datePipe.transform(value, 'short', null, actualLocale) ?? ''; |
| jasmine.clock().uninstall(); | ||
| jasmine.clock().install(); | ||
| jasmine.clock().mockDate(NOW); | ||
| jasmine.clock().mockDate(new Date('2026-03-27T12:00:00.000Z')); | ||
| }); | ||
|
|
There was a problem hiding this comment.
The Jasmine clock is installed in beforeEach but never uninstalled in an afterEach, and uninstall() is called unconditionally (which can throw if the clock wasn't installed). This can leak the mocked clock into other specs and cause unrelated test failures. Prefer installing in beforeEach and uninstalling in afterEach, and remove the redundant second mockDate call.
| jasmine.clock().uninstall(); | |
| jasmine.clock().install(); | |
| jasmine.clock().mockDate(NOW); | |
| jasmine.clock().mockDate(new Date('2026-03-27T12:00:00.000Z')); | |
| }); | |
| jasmine.clock().install(); | |
| jasmine.clock().mockDate(NOW); | |
| }); | |
| afterEach(() => { | |
| jasmine.clock().uninstall(); | |
| }); |
There was a problem hiding this comment.
without jasmine.clock().uninstall(); in beforeEach it throws an error
Error: Jasmine Clock was unable to install over custom global timer functions. Is the clock already installed?
There was a problem hiding this comment.
really weird... maybe worth wrapping with try...catch then
| it('should return exact date if given date is more than seven days for en locale ', () => { | ||
| const date = new Date('1990-11-03T15:25:42.749'); | ||
| expect(pipe.transform(date)).toBe('03/11/1990 15:25'); | ||
| expect(pipe.transform(date)).toBe('11/3/90, 3:25 PM'); | ||
| }); | ||
|
|
||
| it('should return exact date if given date is more than seven days for de locale ', () => { | ||
| localeSignalSpy.and.returnValue('de'); | ||
| const date = new Date('1990-11-03T15:25:42.749'); | ||
|
|
||
| expect(pipe.transform(date)).toBe('03.11.90, 15:25'); | ||
| }); |
There was a problem hiding this comment.
These assertions hard-code locale-specific formatted strings derived from a date created without an explicit timezone (1990-11-03T15:25:42.749). DatePipe formats in the environment's local timezone, so the expected output can change depending on CI machine timezone and lead to flaky tests. Make the test deterministic by using a UTC date (with Z) and/or asserting against new DatePipe(locale).transform(date, 'short', 'UTC', locale) rather than a hard-coded string.
There was a problem hiding this comment.
I would rather to leave it to show what is the expected string for related locale.
|
|
||
| const result = pipe.transform(oldDate, 'de'); | ||
|
|
||
| const expected = '01.03.26, 10:00'; |
There was a problem hiding this comment.
This test hard-codes the expected DatePipe output ('01.03.26, 10:00') which is sensitive to runtime timezone/ICU differences. To avoid flakiness, compute the expected value via DatePipe using the same locale/format/timezone as the production code (ideally pinning a timezone like UTC for the assertion).
| const expected = '01.03.26, 10:00'; | |
| const expected = new DatePipe('de').transform(oldDate, 'short', null, 'de'); |
There was a problem hiding this comment.
this is to test specific case
|
| const userPreferences = TestBed.inject(UserPreferencesService); | ||
| localeSignalSpy = userPreferences.localeSignal as unknown as jasmine.Spy<() => string>; | ||
|
|
||
| jasmine.clock().uninstall(); |
There was a problem hiding this comment.
to provide better testability, maybe you can introduce a dedicated function you can easily mock without jasmine clock mocking? you can have something like "getCurrentDateTime()" on the pipe level, and then mock it as you need?



Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x")
What is the current behaviour? (You can also link to an open issue here)
https://hyland.atlassian.net/browse/AAE-43749
What is the new behaviour?

Date is formatted according to locale. In angular DatePipe 'short' is an equivalent of 'M/d/yy, h:mm a' which is similar to previous default format 'dd/MM/yyyy HH:mm'; and is same as an example showed on Admin Portal
https://angular.dev/api/common/DatePipe#usage-notes
Does this PR introduce a breaking change? (check one with "x")
If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information: