@bennetbo This doesn't seem to work for me: I have a US locale and have disabled the 24-hour override setting, but it renders using 24 hour time on my system.

Rather than trying to figure this out for ourselves, I suggest we use CoreFoundation's builtin time formatting code.

We could either call into it directly, or use it to calculate the current format for us and then continue to format ourselves.

We need to add a dependency on core-foundation-sys and then something like the following code works:

        let str = unsafe {
            let locale = CFLocaleCopyCurrent();
            let formatter = CFDateFormatterCreate(
                kCFAllocatorDefault,
                locale,
                kCFDateFormatterNoStyle,
                kCFDateFormatterShortStyle,
            );
            let fmt = CFDateFormatterGetFormat(formatter);

            let str = CFType::wrap_under_get_rule(fmt.as_void_ptr())
                .downcast::<CFString>()
                .ok_or_else(|| anyhow::anyhow!(dbg!("not a string")))?;

            // CFRelease(locale); 
            // CFRelease(formatter);

            str.to_string()
        };
        dbg!(str); // "h:mm a" when I have the 24-hour thing disabled, or "HH:mm" when it is enabled.

It might be simpler to go one step further and call CFDateFormatterCreateStringWithAbsoluteTime directly on mac to generate the timestamps; but it will depend on how much code is needed to convert between rust dates and cocoa dates (and in the opposite direction with strings).

I installed en_US on my system and can confirm that this does not seem to work. Interestingly neither AppleICUForce12HourTime or AppleICUForce24HourTime seem to be present when using en_US and 12 hour or 24 hour time formatting. I will look into the CFDateFormatter approach, I believe this will also handle more advanced cases, f.e. you can customize the date formatting in macOS converting 01/01/20 to 01.01.20 which is more common in European locales.

My understanding is that CFString will be released as soon as we drop the rust String which is what we are returning here. So there should be no leak, is that correct?

As these globals live for the whole lifetime of the application, the memory will be cleaned up by the OS if zed is shutdown. So we do not need any calls to CFRelease here, is that correct?

core-foundation and core-foundation-sys are used in a lot of crates, should we move those dependencies to the workspace Cargo.toml?

yes please! In general it's best to have dependencies listed there to avoid accidentally having two versions in flight.

Did that, also removed the with-uuid feature, which was referenced in gpui. It does not seem to be used anywhere.