{"id":220,"date":"2017-10-30T16:51:29","date_gmt":"2017-10-30T20:51:29","guid":{"rendered":"http:\/\/expectedly.org\/inclusivetech\/?p=220"},"modified":"2018-08-23T17:38:05","modified_gmt":"2018-08-23T21:38:05","slug":"date-formatting-problems-from-adobe-apple-paypal-and-google","status":"publish","type":"post","link":"https:\/\/expectedly.org\/inclusivetech\/date-formatting-problems-from-adobe-apple-paypal-and-google\/","title":{"rendered":"Date-formatting problems from Adobe, Apple, PayPal and Google"},"content":{"rendered":"

Some of the most irritating cases I\u2019ve seen with hardcoded date formatting come from large, well-resourced tech companies that should theoretically know better: Adobe<\/strong>, Apple<\/strong>, PayPal<\/strong> and Google\u00a0<\/strong>come to mind. I wouldn\u2019t be surprised if Microsoft did similar things, though I use more Adobe, Google and Apple products. As a user of non-US UI region formats and languages, I frequently encounter problems with date and time formatting. The Month\/Day\/Year format is not portable. It should not be the default.\u00a0Never<\/strong>\u00a0default to Month\/Day\/Year, and never hardcode date formatting.\u00a0As soon as you localise your software to something other than English (US), it\u2019s backwards<\/em>. Developers should default to the ISO standard Year\/Month\/Day format and derive settings from users\u2019 set region format or language, prioritising region format.\u00a0<\/p>\n

Adobe<\/strong> products, both on the web and on the desktop, have a long-standing and pervasive problem with hardcoded US date formats regardless of the language the app or website is set to. I\u2019ve mentioned the problems with Behance, but it\u2019s not limited to that site. The document setup screens on Photoshop, Illustrator and other Adobe applications all display dates in the Month\/Day\/Year order, even if you\u2019re set to a different language. I use Photoshop and Illustrator in French. The names of the months and days change to French, but the dates are in the wrong order and the 12-hour clock appears. France does not use the twelve-hour clock. A Month\/Day\/Year date should never<\/em> appear on any applications on this computer; my UI language is set to French and my region format is a customised one with a Day\/Month\/Year preference. I\u2019ve brought it to the attention of the Adobe team, but I haven\u2019t seen any changes yet.\u00a0<\/p>\n

\"Screenshot<\/p>\n

On the App Store, Apple<\/strong> thinks that the date and time format of your local store takes precedence over your own region settings if they differ. Everything related to the App Store shows US Month\/Day\/Year dates, even though my region format is set to UK. The Mac App Store is even weirder. The Available Updates section shows the Month\/Day\/Year date format, even if you\u2019re logged into a UK account<\/em>. The correct Day\/Month\/Year format shows under Purchased and Updated, though. Most Apple apps pick up the correct date format, though. Also, some features in the iWork apps prioritise the UI language over the spellchecker\u2019s language. Just because I have the UI set to French doesn\u2019t mean that I necessarily want dates to appear in French in Numbers, since my spellchecker is set to English. I\u2019ll still take French dates over a date format I didn\u2019t choose though. At least I picked French as my UI language.\u00a0<\/p>\n

Update, 23 August 2018:<\/strong> Apple has improved the way dates appear in both the Mac and iOS App Stores. On the Mac App Store\u2019s update page on the Mojave beta, the user\u2019s region format now takes precedence over the user\u2019s local store settings. The Updates section of the Mac App Store now shows the Day Month Year date format for me, even though I\u2019m logged into a US account. Before, it forced the Month Day, Year format regardless of what my actual settings were. Since iOS 11, the app update section has respected the user\u2019s region format. Unfortunately, review pages on individual apps still default to the local store\u2019s settings.\u00a0<\/p>\n

PayPal<\/strong>\u2019s settings are just as asinine as Apple\u2019s. Because of my account location, I\u2019m still treated to Month\/Day\/Year dates and the 12-hour clock, despite my phone being set to display Day\/Month\/Year dates and a 24-hour clock. I tweeted PayPal support about the app overriding my settings. The representative told me that date and time settings are based on your account location, not your phone or computer settings. This is silly. How difficult is it to respect a user\u2019s settings? iOS and Android make it possible for apps to detect date formatting using their own protocols.\u00a0<\/p>\n

Date formatting in Google<\/strong> search is dependent on the region they\u2019ve detected for your search results. Before they changed all the top-level domains (google.com, google.co.uk, google.de<\/em>, etc) to deliver local results based on your detected IP address, the site you chose determined your date format. I\u2019ve been using google.co.uk for years because it shows dates in the sensible Day\/Month\/Year format. When I noticed Month\/Day\/Year formatting on google.co.uk, I wondered what was going on, since it contradicted my language settings. I found out that I had to go into search settings to switch my results to UK in order to bring back my date formatting preferences. This makes it harder for me to get local results. Why can\u2019t I get local results and <\/em>have my language and date\/time format preferences?\u00a0Other Google products, like Docs, Gmail and YouTube, correctly use language and dialect, not physical location or regional result settings, to determine date formatting.\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"

Some of the most irritating cases I\u2019ve seen with hardcoded date formatting come from large, well-resourced tech companies that should theoretically know better: Adobe, Apple, PayPal and Google\u00a0come to mind. I wouldn\u2019t be surprised if Microsoft did similar things, though I use more Adobe, Google and Apple products. As a user of non-US UI region… Continue reading Date-formatting problems from Adobe, Apple, PayPal and Google<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,9,16,15,3,4],"tags":[],"_links":{"self":[{"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/posts\/220"}],"collection":[{"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/comments?post=220"}],"version-history":[{"count":5,"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/posts\/220\/revisions"}],"predecessor-version":[{"id":265,"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/posts\/220\/revisions\/265"}],"wp:attachment":[{"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/media?parent=220"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/categories?post=220"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/expectedly.org\/inclusivetech\/wp-json\/wp\/v2\/tags?post=220"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}