Calendar and Dates broken/weird??? -original-

Hi,


Since iOS 11, there have been a lot of weird functionning with how Calendar (NSCalendar) and Date (formatters, components, etc) work.

This was so bad that nearly every single Apple app was displaying very weird behavior (and even broken ones) when setting the phone's calendar to anything but Gregorian.


I am not going to upload a Playground (because then this post will take ages to get moderated), but I'm going to pass some code here:

Edit: Well, nevermind, it went into moderation ... this edit is 3 days later, still in moderation ... let's see how long it takes.

Edit2: One week later...

Supposing the device is set to Japanese Calendar or we get a Japanese Date (for example: 1983-01-01, displayed normally as S58-01-01, the S is for Showa era)


Using:

Calendar.current.date(from: japaneseComponents)

we get:

2631-12-31 15:00:00 +0000

normally, we should get: 1982-01-01 15:00:00 +0000 ... Why the weird year? and why did the date shift from 01-01 to 12-31???


Doing something as trivial as:

Calendar.current.dateComponents([.year], from: Calendar.current.date(from: japaneseComponents), to: Date())

we get:

-613

(normally, we should get: 35)

notice: This weird year display has been in almost all of Apple apps (Music, Health, Calendar), and I've filled countless bug reports that are still open for half a year now.


Using:

japaneseComponents.calendar.date(from: japaneseComponents)

we get:

1982-12-31 15:00:00 +0000

note: The date is close but it shifted by one day.

Going all out and trying:

japanseComponents.calendar?.dateComponents([.year], from: japaneseComponents.calendar?.date(from: japaneseComponents), to: Date())

we finally get the correct difference: 35


This kind of behaviour was never here before, any calendar could correctly calculate date differences if given the correct components (that include Calendar and Era), but now it doesn't work anymore.

This broke almost all apps using Calendar to handle internationalization, and forced us to work only with Gregorian to avoid headache.

Replies

What, precisely, is "japaneseComponents"?

Hi,


Sorry, I didn't even see this was finally moderated ... :-/


Anyway, I've had a gist in another post with the same title ( gist.github.com/Einharch/04c4447ea90c20ef102882ba1df36ed8 )


The japaneseComponents are just DateComponents. In this case (when I found the bug), I was getting health data (birthdayComponents) from a device which calendar was set to Japanese.

So, things like the "year" was 55 rather than 1980, but that's fine because the "era" and a "calendar" property were embedded in the components.

The problem here is that operations (like date(from:components), dateComponents(from:date), dateComponents(from date:to date:), etc) all return incorrect values when they should work flawlessly (as they were priot to iOS11).


Full disclosure: I filled multiple bug requests in relation to this (Apple's own apps were, some still to date, broken and saving or showing data on wrong dates, this includes Siri, Calendar App, Health App, Music App, Camera App, Photo Album, etc).

Some of the bug reports have been finally closes, some are open, others have had 0 reaction, so I'm worrying if they're even going to get fixed by iOS 12 ... If not, probably would have to give up on Apple's frameworks and good practices for dates and internationalization.

There is also a reason western apps don't work here in Japan, it's that most handle dates completely wrong and are inusable (like a health app thinking someone is thousands years old, or that some pictures were taken 4000 years ago). This could be reduces greatly if system frameworks behaved correctly.