Hey Android, why no love for UTC? | Hacker News Reader

Hey Android, why no love for UTC?

code.google.com

185 pointsmikelabatt120 comments

This is only issue #164 on the list of most annoying Android bugs as measured by the number of people that got so annoyed that they hunted down the unfriendly Android open source issue tracker, searched through countless other issues for the one they were annoyed by, logged in or created an account, and starred the issue. Some of these bugs have been open for over 7 years.

https://code.google.com/p/android/issues/list?can=2&q=&colsp...

Whoa, EAP-SIM is the top one and... is 6 years old O_O

My Alcatel Pixi could do that but not my both Nexuses (4 & 5x), this is really a shame :'( [1]

Thanks for pointing at the list ;)

[1] http://www.gsmarena.com/compare.php3?idPhone1=5048&idPhone2=...

I remember 7 years ago following this one: https://code.google.com/p/android/issues/detail?id=1109 (Alarm clock produces no sound or vibration). I was an "early adopter" of Android and, as result of this bug, got late for work two or three times. :)

They marked it as "obsolete", but - to be honest - I still wouldn't trust an Android as my alarm for anything.

I'm using Fake Dawn as my alarm app. Hasn't failed me once. But I do use the Android alarm clock occasionally on non-working days, and I've slept through that more than once. It hadn't occurred to me yet that something basic as a timer alarm could be broken.

Oh, great, so it still happens? I really found the "obsolete" status on the issue rather strange, but (as I'm not using Android anymore) it was really just a suspicion.

If it happens to you, maybe you could create a new issue on the tracker, stating that 1109 isn't really obsolete - it still happens.

I use the android alarm clock and it goes off every day for me - I'm not sure you can say "Slept through alarm" means that the alarm didn't go off :)

Yes, I deliberately left that option open because I can't be sure myself :)

Also, my phone's still on Android 4.2 so it could have been fixed since then.

The few times I've used it, the Android alarm app has worked right every time.

I'm confident in saying the countdown timer is not 100% reliable, because several times the screen has very obviously said something like "-2'15" when the alarm has gone off. I didn't really pay this much mind this the first few times, because I mostly use it for timing food, and most food isn't sensitive to an extra 2 minutes. But then one day I was timing a bread roll (8 minutes) and after 10 minutes it was noticeably charred.

If they can't get the countdown timer right I don't see why there can't also be bugs in the alarm clock too. I use it every day, and it's mostly reliable, but I'm suspicious it's failed to go off a couple of times...

I think that's an intentional choice to show you how long past the timer you are if you haven't cleared the timer. It could be useful in some situations especially if you didn't notice the timer and need to know how ruined your food is going to be.

t03m means that the alarm didn't start going off until the timer was 2 minutes overdue.

Yes - this is also with the phone right next to me the whole time, so it's not a case of me missing something. I assume it's possible for the phone to go into some kind of sleep mode whereby timers are checked much less frequently. Seems a bit daft to allow this if there's an active countdown timer that could expire before the next check...

It's really a shame that our two major mobile platforms are a choice between insanely shoddy software and insanely victorian censorship.

Ah my mistake I thought you were talking about the negative time that shows up AFTER the timer has gone off but hasn't been acknowledged. I always use timers on my Moto 360 because it's much more pleasant than the default chirping to hear.

I have been using the stock android alarm clock for a couple of years (and Timely before that), both work like a charm.

I would not be too surprised if they were to fail someday (IIRC it happened multiple times with the iOS clock app), software & time are both complicated..

I'm not sure how Android development works but as a open source project, how come noone implemented simple things like "Add setting to disable all Heads-Up (POP UP) Notifications" yet? Is it the Android team rejecting patches or just lack of interest in getting involved?

Sad. I have a similar example.

Android also conflates language code (say, en-GB) with physical location for many apps. And does not provide a Canadian English (en-CA) -- so if you want to not have the phone constantly spellchecking your emails incorrectly when you type colour, neighbour, etc, and switch it to en-GB to get it to shut up it then starts giving you UK news in the News & Weather app, and reads your turn by turn directions with an English accent.

And there's a similar ticket open about the subject. Also ignored for many years by the Android team.

I've thought about raising a ticket internally (I work at Google) about it, but I imagine it would suffer the same fate.

Sad, and I suppose amusing. I'd prefer to use a spelling checker that accepted all widely-used variations, color as well as colour etc.

Ah, but what does it suggest when trying to help out or autocorrect to the most likely word?

since they're watching me, they should suggest the version that I use the most frequently

Oh, they should. Or preferably they should let you choose that specifically. I was responding towards the idea that they should include all variations when suggesting, not just what they see as your local variation.

Do the Locale-related changes in Android N improve this?

On a related note, I live in Germany and like setting my device's language to en-US. I like the US news, as they are personalized to my taste anyway.

What I dislike is that temperature and distance in a couple of apps are now in US units, which I find unreasonable. I should be able to choose SI units if I want to.

Windows has been getting locale settings right for ages now. I find it sad that Android is so far behind in that regard.

> What I dislike is that temperature and distance in a couple of apps are now in US units, which I find unreasonable. I should be able to choose SI units if I want to.

And I'm in the opposite situation: I prefer British English but want traditional units only.

This really should be user-settable. Heck, even outside of America some folks prefer decimetres over centimetres!

even outside of America some folks prefer decimetres over centimetres!

? Isn't a decimetre a metric measurement?

Yes, and I'm guessing gp was suggesting that I might want my units in dm rather than cm.

even outside of America some folks prefer decimetres over centimetres!

But the US uses feet and inches.

Yes, and in regions outside of America there are folks who prefer to see lengths in decimetres and there are folks who prefer to see lengths in centimetres. Sure, it's easy to convert by sliding a decimal point, but they want to see the order of magnitude they're used to.

Windows has been getting locale settings right for ages now.

That's because those settings were designed before the era of "simplify everything that could even slightly potentially confuse an idiot user" and have been retained from then. I wouldn't be so sure if the future Windows versions will still be as customisable, given that they've already removed things like the ability to change fonts and colours in the UI. It's almost a given that sooner or later someone will come across it, think "let's overhaul/refresh/'enhance the UX'", and turn it into a totally sleek and stylish but less functional version of what it used to be.

Apple manages to do it just fine. Although the advanced settings are a little threadbare on iOS they are very powerful on OSX and still serviceable on iOS.

OS X, just for example, hasn't allowed users to cut and paste files for years and years, for fear that the poor darlings might be confused when cut files, unlike cut text, remain in place until pasted. This isn't just a default setting; they removed file-cutting from the OS.

I love my MacBook, but Apple makes stupid decisions just like anyone else.

This is subjective. How would you cut/paste a 200 gigabyte file anyway?

The way this works on Windows (I think) is that internally, "cut" means "copy file path to clipboard", and "paste" means "move file from old place to new place". Thus, if you want to cut and paste from "Downloads" to "Documents", then it doesn't matter how big the file is: you just change a couple of directory entries without ever changing the file. If you want to do this across file systems, it has to do a copy.

I regularly use cut/paste to move files in Windows and Linux, not sure why the size is relevant.

Ctrl-a to select all files for example, ctrl-x to cut, alt-tab or navigate to a different directory and ctrl-v to paste.

> not sure why the size is relevant

Because typically cutting deletes, not marks. This seems like a great implementation though.

You don't have to load it in memory. The desired behavior can be accomplished with mv.

Amen to that. I find it clumsy to require two finder windows open to move a file between them. Why not cut a file from one directory, open another directory, and paste it there? Ugh!

Most people don't seem to know this, but you basically can cut and paste in the Finder.

First copy the files you want, then move them instead of pasting (Command-Option-V). This gives you the same behavior without the confusion/danger of the files being lost in limbo between cutting and pasting, which I think is honestly better UX design.

In windows if you don't paste the files somewhere they just go back to their original location like they were never "cut" in the first place. Cutting without pasting is not a dangerous or destructive operation.

I think the OP means in all other apps, cutting means removing the selection and put it in the clipboard until it is pasted somewhere. Windows Explorer override this behavior by turning cut into move, which break the semantic and may create confusion that the file might go away if user didn't choose to paste it, if user have used cut in other program but not Explorer.

> This isn't just a default setting; they removed file-cutting from the OS.

They didn't remove anything. No version of Mac OS ever applied the cut-paste metaphor to the filesystem, going all the way back to 1984.

It's a Windows concept.

Cmd-C and Cmd-Opt-V copy and move a file for me just fine in El Cap.

Right, but the Finder does have Copy and Paste. Cmd-C and Cmd-V have worked in the Finder since the very first Mac. It's even in the edit menu.

I suppose they expect you to click and drag to move a file, rather than the slightly unintuitive Cut and Paste on entire files. There's no real physical analogy for a cut.

cmd-opt-v...

All right. Refusing to implement a useful feature for anyone because it's deemed too confusing for novices isn't any better than removing a useful feature because etc., though.

(The recent addition of a special hotkey to paste-with-delete is not much of an improvement, since it still obfuscates the actual, expected behavior (of Ctrl-X) in favor of a different, more obscure, but notionally "friendlier" alternative.)

Meh. iOS gets all of this trivial localization stuff right (correct timezones including UTC, en-CA spelling dictionaries, not conflating locale and location, etc), even though Apple is often accused of being the poster child for oversimplification

I have my Android device set to use en-GB as its primary language for metric units, my spell checker is set to en-US, and my Google News is set to India.

What you want is already possible. However, I do wish the platform allowed a more direct customization of all LC_* stuff.

> Windows has been getting locale settings right for ages now.

Do you mean Windows phone? If so, I'm impressed. If you meant Windows, the computer OS series, well, that would not be a fair comparison for Android. Linux already gets that right.

When I switched from Android to Windows Phone back in 2012, I was surprised with the quality of the localization. I lived in a very small town in the middle of Brazil and even so, the dictionary knew all regional words, town names and prety much anything I tried to type on it.

Everytime I use iOS or Android, I'm quickly reminded that that is not the case outside windows phone.

> for many apps

That's the app developer's fault. They thought they were being smart by saying "oh, if you're in en_GB, lets give you Yelp.co.uk by default". And yeah, sure, that works for most users.

On the other hand, I don't think its fair to fault app developers for that, since there isn't otherwise a way to query the OS for "what country is this user in?" without asking for (and getting) full-precision location access.

On phones, http://developer.android.com/reference/android/telephony/Tel... is probably a better estimate of the user's home country and getNetworkCountryIso() is a good estimate of the user's current country. The fact that my Android phone doesn't have en_CA as a locale option (maybe because they're too cheap to localize the system apps for Canadians, who mix British and American spellings) means that anybody who tries to get the country from the locale region code won't recognize Canadians with this phone.

Thanks, assuming that doesn't require an extra permission, I'm going to use it this week!

Then simply ask them. The whole idea of an app automatically tracking your location and localizing the content without the ability to pin your location is frankly idiotic. It's like whoever comes up with that great plan doesn't know people travel. Websites are especially guilty of that.

In this case the app developer is Google (News&Weather and navigation). So there's that.

And the stubbornness in refusing to add en_CA is confusing. How long could it take? At the risk of talking ill about my own employer (Android is a different team which I have no connection to tho) it seems rather culturally insensitive. I'd put the change together myself if I knew anything about it.

I should note that this is in stock Android on a Nexus. Motorola and others ship their Android with an en-CA locale.

What is good about en_CA? Do you just want colour in spell check instead of color? I have always left my machines in en_US to avoid any bugs due to strange keyboard mappings/layouts and general paranoia that things only get tested when in the standard configuration.

I already stated above. Lack of en_CA and use of en_US means it gives me news, weather from the US, and default measurement units in the wrong form, and it spell checks things wrong.

And switching to en_GB means getting dinged for words like organize, getting odd keyboard layouts, getting news and weather from the UK, and navigator speaking in English accent and dialect.

It's worth nothing that other manufacturers (such as Motorola) ship their Android with an en_CA locale. It's stock Android on Nexus that has the problem. That Google hasn't bothered is rather awful.

I have an Android Priv and it has the option for "English (Canada)" under "language & input", as well as "English (Canada)" for both keyboard inputs. The spell checker is set to "Use system language".

Android version 5.1.1

>Also ignored for many years by the Android team.

The old "closed wontfix (tooboring)" affair seems sadly common.

Last I checked, the stock Clock app has a similar dysfunctionality: in the World Clock tab you can add multiple timezones but there is no option for either UTC or GMT. Weirdly, many of the listed cities are just plain wrong. IIRC, it had Santa Fe, NM listed as UTC+0:00.

At least in latest iOS, UTC is an option in the World Clock tab. It's also an option for system time zone.

It wasn't this way a few releases ago. I remember setting up Liberia time zone when I wanted UTC.

For years there was no Yekaterinburg zone in the clock. No alternative. But you could select it in the system settings. Wtf Google.

Thanks for this post. Now I'll wait a bit longer before moving to an Android phone.

From a developer's point of view, Android is known to be a mess. I thought the reason was the lack of organization between the numerous manufacturers. Now I see that the reason is even more fundamental.

Please don't let this be the reason you don't switch to Android. I think this is a stupid bug to exist, but it hardly affects most people.

The main problem is not the bug itself, but the fact that it's not fixed for so many years.

Maybe not most people, but Iceland is a relatively big country to completely exclude your product from (especially for such a silly reason).

If the OP were Icelandic I think that'd be a pretty good reason not to switch to Android.

Reykjavik is available on the world clock, and if you go there it picks up the correct timezone automatically. The only missing part is that the system timezone widget which you would never normally use doesn't have it.

Also, while excluding a country would be a fairly crappy thing to do, Iceland is the 174th largest country in the world by population, so it's not big relative to very much at all

> From a developer's point of view, Android is known to be a mess.

Source for this?

Not being an Android dev myself, these are some complaints I've heard: There are a ton of resolutions, aspect ratios, and screen sizes. There are a lot of GPU vendors. Driver quality, performance of specific features, little tricks to even use specific features, etc, vary between each of those vendors, and your program should support as many as possible. Different phones have different input methods and peripheral hardware (sensors, notification lights, vibration motors, 3D screens, slide-out keyboards, etc), and trends in the market shift over time.

Compared to Apple, there's a lot of variability in devices, and that may be what they were referring to.

Not that that's a flaw in the Android platform.

> There are a ton of resolutions, aspect ratios, and screen sizes. There are a lot of GPU vendors. Driver quality, performance of specific features, little tricks to even use specific features, etc, vary between each of those vendors, and your program should support as many as possible.

IMO, variety is not a mess - this is has been the norm programming for the consumer space for decades (PC applications, all non-console games, web development). Fixed resolutions & hardware is the exception (consoles, and previously iPhones: now iOS devices are 'fragmenting' too)

Right, so there's a lot of hardware that runs the operating system, while iOS only has a handful of choices, most outdated.

Somehow development for the desktop or the web, where all those points you've made apply in tenfold, is still doing fine.

I hope it has improved since last time I've worked with it (3 years maybe now ?). But on top of my head this were the problems I faced (probably not up do date now, I hope it's much better now):

- The emulator was slow as hell

- Impossible to resize the emulator window dynamically so testing is really slow and painful

- Bugs with manufacturer roms & drivers (hello Samsung !) So you have to test with a lot of devices without guarantee it will work

- you have to copy all the fields yourself when your device pass in portrait mode since everything is being erased (even text fields)

- You need to create some strange XML for just about everything, nothing really works by default.

- No package manager for the libraries, you have to copy some random .jar here and there

- Really poor API. No usable date picker (I'm discarding the default one here), no file picker, no contact manager you can inherit from in built-in, you had to reimplement everything yourself, even a button with an image on it you had to do it yourself.

- Poor consistency in the XML names, it was difficult to guess what meant what.

- The documentation was also hard to browse

- The permission system is close to broken (they are working on that at the moment apparently).

- If your APK is too large, APK expansions (can't remember the exact name now) API's were borderline broken and buggy.

- SD card management was a mess.

- Everything related to layout was difficult to get it right and nothing would ever resize right unless you put a lot of effort into it (the opposite of the web on this).

- Android browser was close to unusable but now that I've checked a recent version, it seems they solved that.

The emulator is fast as hell now (faster than using an actual device, according to them). Many of the other issues you have mentioned here are fixed as well.

With Android Studio, Gradle, and Maven library management is easy now. You just include the dependency and compile.

Better to me than using a third party solution like carthage or cocoapods in the iOS world.

This is endemic to a lot of Google products it seems. Google Calendar has no recognition of UTC/GMT either. It's really irksome since a lot of calendar invites I get that are sent out to global participants have their times in UTC/GMT, and I have to manually convert them to create calendar reminders that fire at the right time.

Any time I, as a human, have to do something that a computer can trivially do, and get right -every time-, is an indication of seriously bad UX.

Without trying to diminish the problem, I'll mention that Google Calendar does support the Iceland time zone, which happens to be equal to UTC.

I've never had a problem with calendar invites in other timezones on Google, and I suspect a number of those come in UTC. Is it possible that the UTC invites you are getting don't actually have the timezone attached? In the absence of a stated timezone I'd have thought assuming the user's current timezone was the safest course of action

You can't create a calendar invite in UTC. Period. This was a year ago; I don't remember the specifics, but either the invite I had was for UTC, and Google Calendar put it in in my own timezone, despite it being clearly UTC, or I had to enter it by hand, and there is no way to specify UTC/GMT by hand in Google calendar. The issue is not an import issue, it's that Google calendar literally does not have the option, at least that I can find. You have to select a region, and there is no special 'UTC' or 'GMT' region, and clicking on the UK does not give you "Greenwich" or "GMT" either.

Though per another comment, yes, if you happen to know a locale whose timezone is the same as UTC/GMT, you can use that, but that's still hilariously unfriendly to the user.

If you ever want a crushing sense of "this project is totally mismanaged", just read its issue tracker.

There are lots of tiny little issues like this in android that have been fixed for a long time in things like GNU. The worst part about android is that it's just so incredibly huge there's no way for anyone to come in and tweak little things.

It's actually pretty straightforward to come in and tweak little things, and there are lots of projects that do it. The problem is that nothing ever gets accepted upstream, and (therefore?) lots of projects never try.

There are chances your changes will be accepted into CM.

How do you go about doing this? Last time I started I was told to pull down 100 GB of code. That's ~ the monthly limit of my connection so that wasn't happening

Damn, this was lodged in 2012!

This seems like a complete no-brainer.

They could call it Z, for Zulu, as the military does.

> Z, for Zulu

I think it might be the other way around.

Right: It was designated with the letter "Z" quite a long time ago, and only later did military (esp. NATO) communication-guides bring "Zulu" into the picture, as a way to disambiguate individual letters like Z, T, C, D, etc. when spoken. </joke-frog-dissection>

I thought "Zulu" was just the common phonetic code for "Z", like Alfa, Bravo, Charlie, etc.

Yes, I believe his joke/point is about the order of causation: The letter came first, and the name followed, rather than the letter being an abbreviation of the name.

For reference, the entire list: https://en.wikipedia.org/wiki/NATO_phonetic_alphabet#Code_wo...

A bit of trivia: there are actually letters assigned to all 24 hourly offsets, Z (Zulu) is only the most well known / useful.

http://www.timeanddate.com/time/zones/military

I would be very glad if they just find a way to make android adjust the clock to the local timezone when I'm traveling. There is a option for that, obviously, but it simple don't work. iPhones and macs take 2 minutes or less to update the clock, but here I am, two days at my destination, and my Nexus 5 still shows home time.

Turn off Data and let the phone connect to a local cell network, as soon as it connects it'll update the time.

I wish it was that easy. I tried, since I bought this phone, all combinations of turning off wifi, data, airplane mode, shutdown phone, hard reboot phone. ;(

It requires two things:

(1) your mobile service provider needs to actually provide NITZ information (I've encountered a Russian provider that simply failed to do it); and

(2) your phone needs to be configured to use that timezone information (settings → date and time → automatic time zone).

But do you know how much work that would be? It could take them multiple minutes to implement!

And twice as long to code review! Meanwhile they're spending time on really useful features like full-screen album art that you can't turn off on your lock screen.

I'm not aware of anybody outside of IT who uses or even understands UTC in place of GMT, so making this change would be a significant backwards step in usability.

It sounds like this is more than just a request for a terminology change. If I'm reading it right, Android's notion of GMT is that it's British time, with a Daylight Saving Time offset in the summer.

Right, Britian uses GMT a portion of the year, and then switches to BST (British Summer Time) during the summer. BST is GMT+1. Android uses GMT and when summer comes around, Android's representation of GMT becomes GMT+1.

> Britian uses GMT a portion of the year,

For that period of the year we actually use a 0-hour timezone over UT1

GMT simply doesn't exist any more. The two maintained timebases are UTC and TAI.

Looks like people cannot set their time zone to UTC. Depending on the device there might not be an UTC equivalent time zone to choose from either, like Reykjavik may not be available on all devices.

The problem to me seems like they are only offering political / locational zones. It does not seem like it would be a significant step backwards to offer an option to set your time zone to a manual fixed offset, which is all the people on the tracker seem to want.

Most people get timezone set correctly automatically to their current location, including folks in Iceland. Specialist users who want to do something odd might discover the unloved system settings widget (it's missing on a lot of phones anyway) and want that to cover their use case, which it couldn't without getting too complex for most users. The specialist timezones are available however, they just need an app like timezone changer to pick them.

I want advocating switching the main time zone selector over to a text box that says, "Enter a valid POSIX time zone string", I was suggesting that at the bottom of the list of selectable time zones (which you only reach generally if you turn off automatic time zone selection) there be a button that says, "choose a fixed offset". Seems like a no brainer.

Every single person in aviation, for starters.

And in space (as in spacecraft). To get GMT, I set my city to Reykjavik.

And space as in astronomy.

Or any global project where people in different countries have to coordinate times for events.

Technically, UTC isn't a time zone.

It's common usage to say or write UTC as a timezone when you mean UTC+0.

Yeah, I was agreeing with the parent in saying that adding a non-timezone to the timezone selection is not a usability enhancement.

Anyone who had to deal with time zones at least once in their lifetime, provided that they have a perfectly natural habit of reading Wikipedia when they find something new to them.

Why not provide both GMT (whatever it means) and UTC for those who really want it? Doesn't have to be either-or.

No reason to have both. A UTC and a GMT clock will read the same time as far as I know.

The reason to have both is that people will search for one or the other based on their habits, and the cost is so, so low to having both.

Anybody who's been in the army.

Short of the very rare case of being a bona-fide expert and up to date in an area "I'm not aware of..." is a deeply flawed input for design and implementation.

Distrust it implicitly.

I'm not the designer. I'm just suggesting reasons why the designers of Android may have chosen the design they did rather than the design the issue demands is the "correct" way

It's not in any way about design, it's about having one more option in an already long long combo box.

My point was, absent doing real work to find out the "right" answer for a range of users, what you or I are aware of is so full of selection bias as to be basically useless to generalize from. It's also an incredibly common failure mode, because you already "know" the answer.

Reply on news.ycombinator.com