IssueTracker

According to the docs it returns "Returns a {@code DateFormat} instance for formatting and parsing dates time values in the DEFAULT style for the default locale.".

The value returned is guaranteed to be a "MEDIUM" format but (in Android apps) the exact time format depends on the user's "Date & Time" -> "Use 24-hour format" setting.

If you _require_ a localized 24 hour format you probably need to use something like android.text.format.DateFormat.getBestDateTimePattern() and provide the pattern skeleton (e.g. "hms" or "Hms").

If you want the 12 vs 24 to be determined based on the Locale (but ignoring the user's 12/14 hour setting) you may need to resort to your own data - I don't think Android currently exposes it via an API.

Although the behavior has changed between releases I believe this is working as intended.

If Android was to change the behavior again an app would have to deal with the behavior on 5.

" ... the exact time format depends on the user's "Date & Time" -> "Use 24-hour format" setting. ..."

This is exactly what I would expect. But it does not work with Android 5.

My code looks as follows:
    DateFormat df = DateFormat.getDateTimeInstance(DateFormat.MEDIUM, DateFormat.SHORT);
    Date date = new Date(cursor.getLong(cursor.getColumnIndex(MyContentProvider.KEY_TIME_START)));
    textView.setText(df.format(date));

And I've selected "Use 24-hour format" in my setting.

But the output is formated with 12-hour format.

That sounds more like a bug and I only looked at the latest code so perhaps the version you have is doing something different. Maybe there was an historic bug with lollipop that has since been fixed.

I'll take a look at 5.0 and 5.1 and the latest AOSP code and see if I can work out what, if anything, has changed.

Can you give me details of which device you are using and build and/or version you are running on it? It would help me replicate what you are seeing.

[Comment deleted]

I'm using a real Nexus 4 with Android 5.1.1 (build number LMY47V)

I have the same behaviour with an AVD using an API level 22.

Could not repeat on a Nexus 4 with LMY47V.

Here's my code:

    Locale.setDefault(Locale.UK);
    DateFormat df = DateFormat.getDateTimeInstance(DateFormat.MEDIUM, DateFormat.SHORT);
    df.setTimeZone(TimeZone.getTimeZone("UTC"));
    Date date = new Date(1420124400000L);
    System.out.println(df.format(date));

Ran inside of an activity.

The only difference between mine and the code from #3 is a fixed timestamp (Jan 1, 2015 3:00 PM UTC) and to force the timezone to UTC so I know what string to actually expect.

Locale : Use 24-hour Setting : Generated String
UK     : Off                 : 1 Jan 2015 3:00 pm
UK     : On                  : 1 Jan 2015 15:00
GERMANY: Off                 : 01.01.2015 3:00 nachm.
GERMANY: On                  : 01.01.2015 15:00

Looks to be WAI.

Please provide code and output, and values for Locale.getDefault(), TimeZone.getDefault() and the date you are formatting if you'd like me to look further.

I can't reproduce the error anymore.

Thanks for your support. I'm sorry to waste your time

You're welcome. No problem.

I got exactly the same problem and I can confirm that the returned value is sometimes 12-hour, sometimes 24-hour format.

Settings are left alone and are set to 24-hour format.

OS is Oxygen OS based on Android 5.1.

It's a real problem as all apps face the same problem, for example Facebook sometimes prints "13:12", somtimes "1:12 nachm." - FitBit has the same problem and now I could pin down the problem within my own apps.

All I use for conversion is this:
private final DateFormat mTimeStampFormat = DateFormat.getDateTimeInstance(DateFormat.MEDIUM,
                DateFormat.MEDIUM);

Why is the behavior not reproducible???

Here are three screenshots:

pic1) my own app using the supplied code:
private final DateFormat mTimeStampFormat = DateFormat.getDateTimeInstance(DateFormat.MEDIUM,
                DateFormat.MEDIUM);
[...]
final String lastTimestamp = mTimeStampFormat.format(new Date(PrefUtils.getLastSyncSucceededTime(getActivity())));

pic2) Facebook having this problem

pic3) My settings

As I said, this error is NOT reproducible 100%. Sometimes it's correct, sometimes it is not!

Hello!

Me and some users of my app are also having this problem.

I think it has something to do with the setting "Use network-provided time" in the Android settings. To be more precisely, when the system clock is adjusted while your app process is still running. But of course the "automatic" setting is one potential "process" responsible to adjust your system clock in the background from time to time.

I am able to reproduce it the following way:
1. Go to the Android "Date & Time" settings.
2. Disable "Automatic date & time" if it is enabled.
3. Make sure the 24 hour format is activated.
4. Set you system clock a few minutes before or after the actual time.
5. Open your app -> The times should now be displayed correctly in 24-hour format.
6. Switch back to the Android settings and activate "Automatic date & time". Make sure that you see how the time is corrected by the system. (On one - rooted - device this did not work automatically. However I was also able to reproduce this by synchronizing the system time with the "ClockSync" app you can get at https://play.google.com/store/apps/details?id=ru.org.amip.ClockSync)
7. Switch back to your app.
=> The app now displays the times incorrectly in 12-hour format, also adding this "vorm." / "nachm." (with German locale).

Workarounds:
- Killing your apps process by going to the last used apps view (Android's square icon button) and swipe you app to the side and restart the app.
- Disabling and re-enabling the 24-hour format in the system settings.

I am not able to reproduce this with Android 5.0 and earlier. It seems that this behavior was introduced with Android 5.1

I am formatting the date the same way like already mentioned in this bug:
DateFormat mFormat = DateFormat.getDateTimeInstance(DateFormat.MEDIUM, DateFormat.SHORT);
mFormat.setTimeZone(calendar.getTimeZone());
return mFormat.format(calendar.getTime());

Maybe this is a fix how Cyanogenmod tries to address this issue?
http://review.cyanogenmod.org/#/c/107718/3

I can confirm the bug still exists in Oxygen OS 5.1.1. I also can confirm that disabling and re-enabling the 24h format solves the problem.

This big is present in Android 6.0.1 as well.
Terrible!!!
Facebook app shows 12 hour format time in Germany - this is so ugly!!!!!! Yikes.
Americans, sorry, but this am/pm thingy is nothing worth using, it is just annoying. :(

This issue still exists for me.
It appears that every time the device's time is changed (either manually or from network), it switches internally the format to 12h. Although the settings still show 24h (if previously selected). To force 24h again, switching it off and on helps as described by #12.

This is still unreproduceable for me on M 6.0.1 and an N DP build.

If you can repeat it please update the bug with:

1) The model of device you are using
2) The version of android being used (e.g. 6.0.1, from the Settings / About Phone)
3) The settings you have for Language, and Date & Time (*all* the settings)
4) Any steps you follow after the device powers on up to the point where you see the problem.

Please also say if the problem occurs in the status bar (bar at the top) and the Android clock app, or the apps you are seeing this in and the versions of those apps.

I can reproduce it.

Device: Nexus 5x, Android 6.0.1
Language: English (US)
Date & time settings: Auto date & time is ON; Auto time zone is ON; Use 24-hour is ON

1) Turn on the phone
2) Open Date & time settings
3) Turn off Automatic date & time
4) Set the time to current time + 3 minutes
5) Open my app and times are in 12h format
6) Return to settings, toggle 24h off and on
7) Return to my app, times change to 24h

The problem is not seen in the status bar or Android clock app. The code my app uses:

                DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.SHORT, Locale.getDefault());
                df.setTimeZone(TimeZone.getDefault());
                return df.format(time);

#17 fixed it for me.
I used the 24h time settings (toogle was on in date & time settings), but it just didn't work (e.g. in the Facebook app). So I went to date & time settings, set the 24h format toggle to off and then on again and now the time format is correct, even after reboot. Weird behavior. So it seems like turning 24h format off and on again fixes it.

Fyi, I did this on:
Device: Nexus 5x
Android version: 6.0.1 (Patch July 5th 2016)
Date & time settings: Auto date & time is ON; Auto time zone is ON; Use 24-hour is ON
Language: German

Thanks for the extra info. We'll try to repeat.

Internal bug reference 30464235.

I've tried to reproduce this issue. Unfortunately without success. The only variable that I can think of that's still not fixed is "my app" or "your app" in the reproduction instructions.

Can someone point to an app (in the Play Store) that they can reliably reproduce this with?

Re: #21

Please see this:

http://www.aqua-mail.com/forum/index.php?topic=4994.0

There are several users of my app (called AquaMail, free in Play) who are seeing this.

I am unable to repro on my device(s) and have posted the relevant code from my app at the link above.

Here it is too just in case:

DateFormat format;
format = DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.MEDIUM);
return format.format(new Date(when));

The bug report on my forum says that there is a difference between doing a "forward" vs. "forward (anonymous)", but both end up calling the above snippet to format the date/time.

Additional data point from a user:

http://www.aqua-mail.com/forum/index.php?topic=4994.msg28911#msg28911

BTW, just an additional data point: I see the same mis(behavior) under Android 4.1.2.
(So, it was not introduced in 5.x., as the OP in that linked code.google thread implied.)

I couldn't reproduce the problem with AquaMail.

The app I use which reproduces it is Syncplicity (https://play.google.com/store/apps/details?id=com.syncplicity.android).

FYI - I did just find / fix a related issue in N (internal bug reference 31762542, see https://android-review.googlesource.com/#/c/281688/ for details). This problem was introduced by the N release: running apps would not properly observe changes to the "use 24-hour format" setting when using DateFormat instances returned by DateFormat.getTimeInstance(), DateFormat.getDateTimeInstance() (for example). It will be fixed in a future release of Android and likely will be backported to N devices by OEMs. This does not explain cases on earlier releases, however.

FYI - I found another bug in the 12/24 format handling, which appears to have been present for a while.

Internal bug reference 32868036 / fix here: https://android-review.googlesource.com/#/q/topic:fix_default_12_24_setting+(status:open+OR+status:merged)

It occurs when the user hasn't toggled their 12/24 hour setting ever (e.g. they haven't touched the "use 24 hour format" setting after a factory reset) AND have selected a locale that defaults to 24 hour formats by default (e.g. German). The device will boot and use the 12 hour format (for some things - those that use java.text.DateFormat, for example, though some aspects of the device will use 24 hour formats - e.g. the clock at the top). If the user goes into settings they would see the "use 24 hour format" setting as "on" (even though they will be seeing some examples of 12 hour formats). If they toggle the setting to "off", then the device will now be consistently on "12", so to get the device _actually_ on 24 hour they must toggle it back to "on" again.

And another one. Internal reference bug 36949180.

When the system clock changes, running apps won't have 12/24 date format preference set properly if the user is using 24 hour formatting (either by default and have never touched the "use 24 hour format" setting, or because they have specifically asked for 24 hour formatting).

To repeat:
1) Set the device into a locale that uses 24 hour formatting by default. e.g. German, English (UK) or make sure the device is set to "use 24 hour formatting" explicitly
2) Start an app that uses java.text.DateFormat MEDIUM or SHORT format. Observe the app thinks it should be using 24 hour formats.
3) Modify the system date or time using settings.
4) Observe that the app (which should have remained running) now thinks it should be using 12 hour formatting.

This affects users of java.text.DateFormat standard SHORT and MEDIUM time or date/time formats. Many of the visible clocks on the device do not use this, preferring android.text.format.DateFormat.is24HourFormat instead and then supplying / constructing their own pattern using android.text.format.DateFormat.getBestDateTimePattern() with (for example) "Hm" or "hm" accordingly to get the right 12/24 hour pattern. Code doing it this way would be unaffected by this bug (and the other bugs I've discovered).

Note: The system clock change doesn't have to be explicitly triggered by the user. A lot of devices have automatic time setting so this could happen if the cell network or an NTP check causes an adjustment.

This also appears to have been around for a while.

I have submitted fixes for all of the bugs I discovered. Bug 36949180 was submitted internally because of various changes to the android framework that would have meant rolling the fix twice.

All fixes will be available in a future release of Android.

For apps looking to workaround issues 32868036 and 32933009 I suggest the following:

    boolean use24Hour = android.text.format.DateFormat.is24HourFormat(context);
    final String skeleton = use24Hour ? "Hm" : "hm";
    final String pattern = android.text.format.DateFormat.getBestDateTimePattern(locale, skeleton);
    DateFormat formatter = new SimpleDateFormat(pattern, locale);

... for SHORT date. MEDIUM would use skeletons of "Hms" / "hms" instead.

The code above bypasses the internal code that keep the (incorrect) in-memory state that tracks whether the user prefers 12 or 24 hour time formatting. AFAIK, android.text.format.DateFormat.is24HourFormat has always used the underlying user setting.

is24HourFormat() was added in API 3. getBestDateTimePattern() was only added in API 18.

Are fixes deployed?

"Deployed" is a tricky term with consumer devices, particularly Android ones. The fixes are now in the Android source code and all but the last one are in AOSP so fully visible to anybody. Given the timing of the fixes I'd say they should be in the next major release. The "O" release is in developer preview right now.

OEMs are free to apply patches to their devices earlier providing they don't break compatibility tests (which these probably wouldn't), but I'd be surprised if they had for these. They typically wait for Google to release the next major release and take all the fixes at the same time.