fix: respect system 24-hour time setting - #1111
Open
guzino wants to merge 9 commits into
Open
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
jvsena42
requested changes
Jul 29, 2026
ovitrif
reviewed
Jul 30, 2026
jvsena42
self-requested a review
July 30, 2026 13:22
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #677
This PR makes activity timestamps follow the device's 12/24-hour time setting.
Description
DatePattern.ACTIVITY_TIMEwash:mm, a 12-hour pattern with no meridiem, so a payment received at 15:23 rendered as3: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)inui/utils/DateText.kt, backed by aUiDateStyleenum (TIME,DATE,DATE_TIME,DATE_TIME_YEAR) inext/DateTime.ktthat owns the patterns. The clock format comes fromLocalIs24HourFormat, provided once inContentViewbyrememberIs24HourFormat(), which registers forACTION_TIME_CHANGEDso timestamps follow a change to the setting.ActivityRowandActivityDetailScreenpick a style and call it. Neither builds a pattern nor sees the flag. Picking the style by age is the pureuiDateStyleFor(timestamp, today, zone)inext/DateTime.kt.ext/Numbers.kt(toActivityItemDate,toActivityItemTime) is removed as superseded, along with theACTIVITY_*pattern constants and the unusedINVOICE_EXPIRY, leavingDatePatternas plain constants.Instant.formatted()takes optionallocaleandzoneso patterns can be asserted without depending on the CI machine's locale or timezone. Existing call sites are unchanged.ChannelDetailScreenstill hardcodes 24-hour viaDatePattern.CHANNEL_DETAILS(#1110), andtoLocalizedTimestampdefaults toLocale.USso App Status and Backup timestamps ignore the device locale (#1112). Both are separate screens and are left out here; withuiDateTextin place each becomes a two-line adoption.Preview
QA Notes
Manual Tests
14:38), matching the status bar.2:38 PM.regression:Switch the device to a non-English locale and confirm activity dates still render with a localized month name.Automated Checks
DateTimeExtTest.kt: eachUiDateStylein 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.just compile,just test,just lintall pass, no new detekt findings.