Sure.

For a while now, if you needed the time from your computer, and it was running UNIX or a variant, you'd use something like gettimeofday() (it's clock_gettime() now) which would hand you seconds since the epoch at midnight January 1, 1970 in UTC and microseconds/nanoseconds depending. You'd take the seconds, wash it through localtime_r to adjust for the local time zone, and you'd have a struct you could feed to strftime() for formatting.

So my beef with time formats, and what I presume ChickenLadyLovesLife's beef is, is that when the time format is "wrong" for whatever reason, given the similiarity between the backends of modern time systems, it's "wrong" for reasons other than technical limitations. You've got a count in seconds since the beginning of time, and a function that's been around for decades that can do whatever stupid stuff you want. Military time, month printed out, day of week printed out, two character years, four character years, seconds, julian day, Doing something silly like day of year, hour of day, and am/pm ("%j %I %p") is just as easy as something practical like a large fluffy timestamp, or a minimalist four characters military time ("%H%M"). The hard part was getting the time from the GPS or cell phone tower or wherever. The easy part is the time format. Windows also exists, and uses something similar. Modern programming with C++ or Python will have libraries ( and datetime, respectively) that work the same way, and both those examples use strftime() semantics.

So, if you're unhappy with the way your device prints out time, the reason behind it isn't the clock part of it, it's the display part. There was some rationale on Android's behalf for adopting the hour over minutes style, but it wasn't because their available horizontal character limit dropped from four (five if you count a colon) to two. Maybe they can get more data widgets displayed around the time in a little halo? I don't know, I don't use android stuff anywhere. If it was apple I'd assume they did UX testing about half height characters and readability.

So, now to the "end goal" part of what I wrote before. The hard part is done and a solved problem, and most time formats work fine for what they do. tmux is giving me ("%H:%M %d-%b-%y") which works fine, and my desktop environment (DE) is using ("%a, %b %d %H:%M") which is fine. The other DE is using ("%b %d %H:%M") which is fine. All perfectly usable, all used the three character representation of the month avoiding problems between dd/mm/yy or mm/dd/yy, and all of those are adjustable to an extent with two of the three kicking back to strftime() if I needed it. So what did android get when they paid developers to make the change to hours on top of minutes? Is there a study I missed that of a group of people who'd never seen a clock before and had no concept of time found the "%H\n%M" style more easy to read? If that's true, then was it worth irritating the subset of people who are going to care about the change to pick up the other group? I personally don't see a point in paying to make the change unless they're expecting to make more money from it, which at the core of a lot of things in the world these days. Here's something that worked fine, but now it's being changed to work differently but no better.