fix: respect system 24-hour time setting

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.

[guzino]

Fixes#677

This PR makes activity timestamps follow the device's 12/24-hour time setting.

Description

DatePattern.ACTIVITY_TIME was h:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as 3:23. That is wrong for anyone on a 24-hour clock and ambiguous even for 12-hour users. The two neighbouring row patterns (ACTIVITY_ROW_DATE, ACTIVITY_ROW_DATE_YEAR) were hardcoded the other way, to 24-hour, so the same activity row changed clock format depending on how old the item was. Nothing in the app consulted the system setting.

Rather than pass a 12/24-hour flag around the screens, this adds one entry point for user-facing timestamps:

• uiDateText(timestamp, style) in ui/utils/DateText.kt, backed by a UiDateStyle enum (TIME, DATE, DATE_TIME, DATE_TIME_YEAR) in ext/DateTime.kt that owns the patterns. The clock format comes from LocalIs24HourFormat, provided once in ContentView by rememberIs24HourFormat(), which registers for ACTION_TIME_CHANGED so timestamps follow a change to the setting.
• ActivityRow and ActivityDetailScreen pick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pure uiDateStyleFor(timestamp, today, zone) in ext/DateTime.kt.
• ext/Numbers.kt (toActivityItemDate, toActivityItemTime) is removed as superseded, along with the ACTIVITY_* pattern constants and the unused INVOICE_EXPIRY, leaving DatePattern as plain constants.
• Instant.formatted() takes optional locale and zone so patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.

ChannelDetailScreen still hardcodes 24-hour via DatePattern.CHANNEL_DETAILS (#1110), and toLocalizedTimestamp defaults to Locale.US so App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; with uiDateText in place each becomes a two-line adoption.

Preview

QA Notes

Manual Tests

• 1. Set the device to 24-hour time (Settings > System > Date & time). Receive a payment, then check the activity row and activity detail: both show the time on a 24-hour clock (e.g. 14:38), matching the status bar.
• 2. Set the device to 12-hour time and reopen the activity list: the same entry reads 2:38 PM.
• 3. Check an activity item from earlier this year and one from a previous year: the date is unchanged and the time follows the same 12/24-hour choice as today's items.
• 4.regression: Switch the device to a non-English locale and confirm activity dates still render with a localized month name.

Automated Checks

• Unit tests added in DateTimeExtTest.kt: each UiDateStyle in both clock formats, midnight and noon boundaries, month-name localization, and timezone handling. All use a fixed instant with explicit locale and zone so they are deterministic.
• Local: just compile, just test, just lint all pass, no new detekt findings.
• Verified on an emulator in both 12- and 24-hour modes with a regtest transaction.

[ovitrif]

untested neutral review round 1 done, submitted some remarks

[jvsena42]

tAck

[ovitrif]

@greptile re-review latest tip

[ovitrif]

utAck, thanks @guzino for your first ready-to-merge PR 👏🏻

To many more 🍻 !
This improvement might be released in the near future alongside a planned patch that addresses the most commonly occurring PROD crashes.