Default 24 hour notation for search criteria

[rogin]

Adds a checkbox to the Messages Browser and Events Browser which toggles the time format of the time input fields between HH:mm and hh:mm aa. On form load and on search reset, it defaults to 24hr notation.

I used most of the previous PR, but I changed the listener to one that responds to JCheckbox.setSelected(bool). Changes to the .form files were also included, but those may be completely unused.

Related
Previous PR - nextgenhealthcare/connect#5989
Summary table in #121

[mgaffigan]

Can this respect the OS preference instead? It looks like Java provides access to the user's preferred 12/24 time format via java.locale.providers=HOST for Windows and Mac on Java 11+.

import java.time.LocalTime;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;

public class Main {
    public static void main(String[] args) {
        System.setProperty("java.locale.providers", "HOST");
        System.out.println(LocalTime.now().format(DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT)));
    }
}

Prints 17:44 on Windows with 24-hour time set in Control Panel on Java 17.

[rogin]

Can this respect the OS preference instead? It looks like Java provides access to the user's preferred 12/24 time format via java.locale.providers=HOST for Windows and Mac on Java 11+.

import java.time.LocalTime;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;

public class Main {
    public static void main(String[] args) {
        System.setProperty("java.locale.providers", "HOST");
        System.out.println(LocalTime.now().format(DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT)));
    }
}

Prints 17:44 on Windows with 24-hour time set in Control Panel on Java 17.

I like the idea. Your link omits linux compatibility in Oracle's v11, so perhaps linux guys can check their systems. If good, I could add a new slot in Settings>Administrator>User Preferences, with an option like "Use 24 hour notation for search criteria" with Yes, No, Use system default. I'd model the logic of reading and storing the boolean like used for "Import code template libraries with channels".

[rogin]

Not bad

[tonygermano]

I like having it configurable as a user preference. I'm not sure how useful it would be to pull from system preferences, because all of my desktop clocks are set to 12-hour format for display, but I would certainly rather use 24-hour format for search parameters instead of needing to add AM/PM. Search results already display in 24-hour format, and that is not configurable.

I know with user preferences they can either be saved in the database (which would follow the user to multiple devices when logging into the same server) or to the local machine, which won't follow the user if they log in on multiple devices, but should work across multiple server instances when logging in from the same device.

I think my preference would be to make it a local user preference that would default to 24-hour when not set. I think that follows the spirit of the original PR.

I'm not sure what the other implications are for forcing the locale provider to HOST. According to https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/spi/LocaleServiceProvider.html, that property is supposed to set the user's preferred lookup order. HOST is not always available in all runtime environments, nor is it even present in the default order of CLDR,COMPAT.

[mgaffigan]

I think the way @rogin has done it is on point. Use the system preference by default, allow it to be overridden. We're specifically talking about a UI aspect - not a server or backend thing where there's a single right answer.

Respecting the user's system preferences is a UX best practice. People can be peeved when you do not (especially the "dark mode is the one true mode" crowd). Font size, contrast, motion preferences, dates/number/money formatting, theme/dark/light mode are all available from the system on Windows/Mac/Android/Web.

[tonygermano]

I'll try to bullet-point my previous comment. I'm not disagreeing with you about respecting user preferences.

1. The system property java.locale.providers is a user preference. The proposed change would ignore the user setting that property and override it.
2. I am unsure of the consequences of changing the default value from CLDR,COMPAT to HOST and I think that needs to be evaluated outside the context of this PR only.
3. 24-hour should likely be the default regardless of the setting for the user's system clock because
   1. The search results are already in 24-hour format, and that is not configurable. The search parameter should match.
   2. 24-hour format is easier to type
   3. Many people don't change their system clock to 24-hour format, nor do they have a desire to. Searching a log and glancing at a clock are not the same use case.
4. By storing it as a local preference, if the user sets the value to 12-hour one time, it should apply to all servers they access from that client device.

When it comes to the release notes I think this would capture the two choices we are discussing:

1. When searching messages or events, the time selection now defaults to 24-hour format. If you prefer to retain the previous behavior go to Settings-> User Preference and change the "Message searches use 24-hour format" value to "No."
2. When searching messages or events, the time selection now supports 24-hour format and will match the settings of your system clock by default. If you prefer to change this behavior to always use 12-hour or 24-hour format, go to Settings-> User Preference and change the "Message searches use 24-hour format" value to "Yes" or "No" accordingly.

I think the first option is cleaner and will require fewer people to actually need to go in and change the setting.

[mgaffigan]

@tonygermano, This is not my issue - so I'm not pushing here. I stand by the comment re: best practice, but will not oppose regardless of outcome of this PR.

[rogin]

I agree with Tony's first option. I'll update the code.