Follow user's time format setting (12 or 24 hour) #1730

chrisbobbe · 2025-07-22T03:43:36Z

cc @alya for screenshots below.

chrisbobbe · 2025-07-22T03:53:28Z

Conveniently for making screenshots, I could fit three things on the screen at once:

A global time in message content
A short message timestamp in the message list
A long message timestamp in the message action sheet

`user_settings.twenty_four_hour_time: false`

Before	After

`user_settings.twenty_four_hour_time: true`

Before	After

rajveermalviya

Thanks @chrisbobbe! This works great, and LGTM.

chrisbobbe · 2025-07-22T14:55:01Z

Thanks for the review!

gnprice

Thanks for building this! Comments below.

gnprice · 2025-07-22T20:18:03Z

lib/widgets/message_list.dart

    final messageListTheme = MessageListTheme.of(context);
    final zulipLocalizations = ZulipLocalizations.of(context);
+    final formattedTimestamp = MessageTimestampStyle.dateOnlyRelative.format(
+      timestamp,
+      now: ZulipBinding.instance.utcNow().toLocal(),


Using the binding is a good idea. How about having the callee invoke it? Then it doesn't need to be a parameter that each caller passes.

(Potentially that happens after the other commits — it might be simpler to do that change after this one:
26d5ef5 msglist [nfc]: Finish centralizing on MessageTimestampStyle

than vice versa.)

I was thinking we'd want format to be a pure function, so not a right place to check the clock. And I guess that callers would be more likely to take care of refreshing relative times (e.g. #293, #891) if they're responsible for reading the clock. What do you think?

Hmm, refreshing relative times is an interesting point. I guess let's leave it this way for now, and we'll see what we come up with to organize the code when we go to handle that.

gnprice · 2025-07-22T20:26:59Z

test/widgets/message_list_test.dart

-    final now = DateTime.parse("2023-01-10 12:00");
-    final testCases = [
-      ("2023-01-10 12:00", zulipLocalizations.today),
-      ("2023-01-10 00:00", zulipLocalizations.today),
-      ("2023-01-10 23:59", zulipLocalizations.today),
-      ("2023-01-09 23:59", zulipLocalizations.yesterday),
-      ("2023-01-09 00:00", zulipLocalizations.yesterday),
-      ("2023-01-08 00:00", "Jan 8"),
-      ("2022-12-31 00:00", "Dec 31, 2022"),
-      // Future times
-      ("2023-01-10 19:00", zulipLocalizations.today),
-      ("2023-01-11 00:00", "Jan 11, 2023"),


For these test cases of the "relative date" logic, it's quite useful that the different times are all right next to each other and next to the value of "now". When you look at "now" and then read through the different cases, they tell a legible story about how the intended logic works and what edge cases are successfully covered.

gnprice · 2025-07-22T20:28:55Z

test/widgets/message_list_test.dart

+    doTests("2023-01-10 23:59", (style, expectTwelveHour) => switch (style) {
+      MessageTimestampStyle.none => null,
+      MessageTimestampStyle.dateOnlyRelative => zulipLocalizations.today,
+      MessageTimestampStyle.timeOnly =>
+        expectTwelveHour ? '11:59 PM' : '23:59',
+      MessageTimestampStyle.lightbox =>
+        expectTwelveHour ? 'Jan 10, 2023 11:59:00 PM' : 'Jan 10, 2023 23:59:00',
+      MessageTimestampStyle.full =>
+        expectTwelveHour ? 'Jan 10, 2023 11:59 PM' : 'Jan 10, 2023 23:59',


Meanwhile, all these non-relative formats don't really benefit from most of the different test values that are there for the relative-date format. After seeing how timeOnly comes out on one timestamp that's at 11:59pm, there's nothing new learned from seeing another such timestamp.

gnprice · 2025-07-22T20:30:34Z

test/widgets/message_list_test.dart

+            withClock(Clock.fixed(DateTime.parse("2023-01-10 12:00")), () {
+              // TODO take the message timestamp as an int, like [Message.timestamp]?
+              final timestamp = DateTime.parse(messageTimestampStr).millisecondsSinceEpoch ~/ 1000;


No, it's useful that the test source code has it as a readable date/time string. That's what makes it possible for a human reading the tests to judge whether a given expected answer is right, and also to think about what edge cases there might be and then look to see if they're covered by the given examples.

gnprice · 2025-07-22T20:47:58Z

lib/api/model/initial_snapshot.dart

+  @JsonKey(
+    readValue: JsonNullable.readFromJsonAssertingPresent<bool>,
+    fromJson: TwentyFourHourTimeMode.fromApiValue,
+    toJson: TwentyFourHourTimeMode.staticToJson,
+  )
+  TwentyFourHourTimeMode twentyFourHourTime;


How about without the readValue?

That'd be simpler in the code. I believe the only difference in behavior is that if a server didn't send the value at all, this would treat it the same as null, whereas the PR's current version would treat it as malformed.

I don't think we gain anything by rejecting a case where the server doesn't send the value. In general across our API binding we treat that the same as sending null; the only exceptions are in a small number of places where the API's semantics actually give different meanings to absent and null. (In fact it looks like just one so far: deliveryEmail on RealmUserUpdateEvent.) But it's not doing that here; if it were, "asserting present" would be wrong.

(And then can we also eliminate the other JsonKey arguments? What if we rename or alias TwentyFourHourTimeMode.fromApiValue as fromJson?)

(And then can we also eliminate the other JsonKey arguments? What if we rename or alias TwentyFourHourTimeMode.fromApiValue as fromJson?)

I think when the .g.dart files are generated, an enum's fromJson or toJson methods (when present) are never actually used, unless you ask for it with those JsonKey arguments.

I'd normally just do @JsonEnum(valueField: "apiValue"), but when I do that, dart run build_runner build gives an error:

Failed to build with build_runner in 18s; wrote 381 outputs. log output for json_serializable on lib/api/model/initial_snapshot.dart E `JsonEnum.valueField` was set to "apiValue", but that field does not have a type of String, int, or null. package:zulip/api/model/model.dart:303:6 ╷ 303 │ enum TwentyFourHourTimeMode { │ ^^^^^^^^^^^^^^^^^^^^^^ ╵

(The apiValue field is typed bool?.)

Hmm, I see. OK, then.

gnprice · 2025-07-22T21:09:06Z