macOSは新元号に対応するんですかね？情報が無いよ

あのさ、Apple。東方の小さな島国の年号だからって軽く見てやしませんかね？

発表後にアップデートで対応するから心配するな

>>2
そうじゃねーよ。いきなり未知の年号が登場したら
アプリが困るだろうが。

4/1公表の4/11実施だぞ。10日しかない。
Appleの対応を含めりゃアプリが検証・対応する時間は数日しかないだろ

なにがどう変わるのか、事前に検証するにはどうすれば良いのか？
その方法を提供しろって

訂正 4/1公表の5/1実施だぞ。1ヶ月しかない
（4/11は元々の公表する日だったみたい）

Unicodeにない漢字だったりして

どんなアプリが影響を受けるん？

システム環境設定→日付と時刻→暦法の設定によってはいろいろな日付が和暦で表示されるから
表示だけならあらゆるアプリが影響を受けるよ
動作に影響するの可能性があるのはNSDateFormatterで和暦を解釈する場合とかかな

まあアップデートが来るでしょ

元号なんざ、ガラパゴスの極致。めんどくさいし、非合理的だし、いい機会だから即刻廃止願います。

>>7は日付と時刻じゃなくて言語と地域だった

新元号対応がギリギリまで遅れるのはAppleなどソフト会社のせいではなく

新元号をギリギリまでどこにも公表しない安倍政権・自民党と
改元当日まで新元号を公表するなと主張してる日本会議・神道政治連盟が元凶

よっぽどアホな作りしてなきゃ数行書けば対応できるはず

>>5
安晋だから大丈夫

>>10
> 新元号対応がギリギリまで遅れるのはAppleなどソフト会社のせいではなく
いや、方針とか発表しろよｗ

Windowsはレジストリにキー追加するだけで対応出来るようになってるから
今から新元号が追加された想定でテストできるんだぞ

ついでにいうと、本当は4/11に公表だったのが、Microsoftがそれじゃ間に合わねーよって
言ったから4/1に公表が前倒しになった。Microsoftの影響力はすごいや

4月1日だと嘘だという可能性もある

>>3
恥ずかしすぎて草

>>13
macOSとWindowsの普及率考えればまぁ当然だろうな

MSすごいって言いたいだけの人だったか…。
レジストリ対応ってなんか危なっかしいな。まあ仮対応みたいなもんだろうが。

元号廃止で構わん
西暦変換が面倒くさい

>>17
レジストリは駄目って言いたいだけの人ですか？
レジストリが駄目ならファイルに保存するのもだめなんでしょうねｗ

>>17
MSがすごいじゃなくて
Appleはいったい何やってんだよ！って言いたい人なんじゃないか

流石にソースコードレベルではすぐ対応できるようにしてあると思うけどね。
レジストリはさすがに永遠にそのままはダメでしょw

だからなんでレジストリでは駄目なんだ？
そんなことを言ってるとmacOSや他OSで同等のやり方を
やっていることがわかった時、お前恥をかくだけだぞ。
理由を言っておけって。

保存すること自体はどっかにしなきゃならんけど、なぜよりにもよってレジストリみたいな比較的不安定な場所？という疑問はある。
過去の元号なんて変わりようがないのに、消したり書き換えたりが容易な場所に保存する意味ってあんの？
よく言えば柔軟性のある仕組みにしてある割に明治以降しか対応してないようだし。

レジストリがなにか特殊なものだとでも思ってるの？
実体は単なるファイルなんだけど。
プログラムだって実体は単なるファイル

> 過去の元号なんて変わりようがないのに、消したり書き換えたりが容易な場所に保存する意味ってあんの？

バイナリだってバイナリエディタで書き換え可能だし

macOSの和暦実装はおそらくICUに依存してて
ICUの方は既に対応が済んでいる(今の所新元号はＱＱになっている)から
どこかのタイミングでアップデートされるんでないの
https://github.com/unicode-org/icu/pull/111

ICUの実装としては/usr/share/icu以下にバイナリデータがあってそれを参照していると思われる

問題は、MacがICUを使っているかどうか、
いつ対応するのか、とい話なわけだが

いやICUは使ってるよhttps://opensource.apple.com/source/ICU/

問題は、Mavericks以前にちゃんとアップデートが来てくれるかということだが……
来るよね？

ちなみに10.12で確認したところ-[NSDateFormatter stringFromDate:]の場合こんな感じでICUを呼んでる
* frame #0: 0x00007fffdf0753cd libicucore.A.dylib` udat_open
frame #1: 0x00007fffca79f851 CoreFoundation` __cficu_udat_open + 65
frame #2: 0x00007fffca79eaf9 CoreFoundation` __ResetUDateFormat + 425
frame #3: 0x00007fffca81ef90 CoreFoundation` __SetUpCFDateFormatter + 480
frame #4: 0x00007fffcc184047 Foundation` -[NSDateFormatter _regenerateFormatter] + 329
frame #5: 0x00007fffcc183d90 Foundation` -[NSDateFormatter stringForObjectValue:] + 303

>>31
それでいつ公開するんですか？
未定ですか？困るんですよね、先がわからないと

レジストリってそこだけ集中的にアクセスしてあっという間に壊れるアレ？

>>33
アクセス集中程度で壊れるなんてmacOSぐらいだろｗ

んだな、sadMac連発になります。

レジストリ壊れたことある？
自分でいじって壊したことすらないんで意外と丈夫なイメージだが

>>36
レジストリが壊れたー。Windowsはクソ
フリーズしたー。Windowsはクソ
起動しなくなったー。Windowsはクソ
HDDも壊れたー。WindowsがHDDを壊した

って言ってる間抜けなら見たことがあるｗ

Appleもこれぐらいやってくれないものかね？
いつまでになにをどうやってくれるのかさっぱりわからん
上の方でicuがどうとか出てたが、icuに依存するところは対応されるんじゃね？という希望的観測で
Appleが提供するAPIレベルで明言されてない。フレームワークとかの日付関数、全部大丈夫なんか？

Japan New Era Name Support Blog
日本マイクロソフトの新元号 (和暦) 対応に関するサポート情報のブログです
https://blogs.technet.microsoft.com/jperablog/

・2017年9月11日 新元号 改元のサポート ブログ
・2017年9月12日 新元号 改元の対応のプロセス
・2018年4月02日 新元号への対応についてのアップデート
・2018年4月20日 Windows 10 機能更新プログラム (2018 Spring Release) における元号のレジストリ更新について
・2018年5月1日 新元号への対応に向けた検証とテスト ケースについて
・2018年6月25日 .NET Framework の新元号対応予定について
・2018年6月25日 新元号プレースホルダーのレジストリを個別に削除、追加する方法について
・2018年7月20日 弊社製品の新元号対応予定について
・2018年9月21日 Windows 10 Version 1803 における新元号の仮定義の削除について
・2018年10月9日 新元号検証ラボと新元号に関するセミナー開催予定のご案内

>>1
こういう会社ですから
米AppleがiPhone地図から「竹島」を削除
http://news.livedoor.com/topics/detail/15229241/

Apple社、地図で”日本語設定”以外が全部「独島」表記が物議に…
https://blog.goo.ne.jp/sakurasakuya7/e/69adaeed062815843f01056aa45fc241

アップルはアホなとこある。

新元号アップデートでExcel 2010が起動しない不具合、Microsoftが削除を呼び掛け
https://internet.watch.impress.co.jp/docs/yajiuma/1160935.html

Windowsの情報いらね
Microsoftを社会から削除しよう

Excelの元号トラブルは
Numbersなど互換アプリにも関わる問題

Excelで新元号で表示されるのに、
Numbersで開いたら「平成」って
表示されることになるんかな？

文字として入れない限りは
日付けとか時間はデータとしてはあくまでも数字だからな

「4月1日の公表日の決定についてマイクロソフトは関与しておらず、4月10日のWindows Updateで
新元号に対応するかどうか政府と調整はしていない。当社としては、改元の日に間に合うように最大限努力する」
http://ascii.jp/elem/000/001/798/1798005/

っていうか、ぶっちゃけmacOS上で元号表示にして使ってるか?
元号が変わるから騒いでるだけちゃうんかと。

Mac OS Xで元号が使えるようになった(-> ICUを統合した）のは割と後の方
だった記憶しているが... それまで誰も気にしていなかった記憶が。

あと、そもそもアプリとかで元号の文字列を持っているのもあるんじゃ。

Cocoa/CoreFoundationで元号が扱えるようになったのは10.3からかな

ことりちゃんが一髪変換できれば、他になにも望まない

>>48
おっと、意外と古くからあるみたいですね。

そういえばUnicode方面の文書では、平成の開始が1989年1月7日となってるなあ... 1月8日が正解。
ICUもコメントではそう書いてある。けどコードではちゃんと1月8日となってるw

macOS上ではFinderの日付やらカレンダーやら、確かに元号表示できるけど、平成の最初の年とか
「1年」ってなるなあ。「元年」じゃ?

>>50
unicode文書の変更は会議にかけて過半数の賛同を取る必要があるらしいから
それは間違いを正す場合でも同じと聞いた

つまりは先端的団体に見えてもお役所には変わりないと

Apple A13にはx86/x64デコーダ搭載か

量子CPUはまだですか？

macOSのカレンダーで少し遊んでみた。

あれ、日本が太陰暦だった頃のずれが正しく考慮されてないような。
例えば明治の始まった日、慶応でいうと4年9月8日は西暦1868年10月23日のはずだが
暦のフォーマットを和暦からグレゴリオ暦に変えると1868年9月8日になる。

MacOSって19世紀のカレンダーにシステムレベルで対応したことあったっけ？

4で割って100で割ってってあのルールを緩和するために1904年（うろ覚え）スタートにしたとかって奴かな
おかげで2000年問題が生じないとかなんとか
前世紀の遺物については当然記憶も定かではないｗ

>>57
　↑

>>56
>>55のような日付データの扱いに関して、動作を見ると「対応してない」というべきかと。
でも表示だけは明治はおろか無駄に大化とかも出せるんだよなー

例えば純真な学生がMacのカレンダーを使って「本能寺の変は天正10年6月2日か。メモっとこう」
みたいなことをやったら間違い。ってしないかw

ま、ICU自体がその辺はあまりちゃんとしてないみたいなので、それを受け継いでるのかな。
こんなのはとっくに対応してるのかと思ってた。

和暦と西暦変換が必要な表計算ソフト位が影響あるんじゃないの？
Microsoft社は一般公開前に教えてくれと日本政府に言ってあるんじゃないかね？

新元号も漢字2文字なんだろうし、UNICODEに無い漢字は使わないでしょう
三国志くらいにしか出てこない人名漢字なんて使わないw

新元号は、安倍か晋三

>>61
すでに別の用途で一般的に使われてる単語にはしないよ

じゃ　安三でどうだ？

せめてググってから言えよ

ググったのか。おつ

ググれっていうのは、言葉を知らんお前に対してだよ
俺は知ってるからググっていない

○○ゲートウェイとかならんだろうな。

愚虞ではどうじゃ？

>>8
チョンコロ乙

次の元号は神無でいいよ、

>>1
元号なんて廃止でいいだろ
何年前か即座に分からなくて困るから不便極まりない

キリストの誕生年さえわからなくなる西暦を廃止した方が良いぞよｗ

人類は未だに「月」という暦の単位から離れられない。
すなわち人類とは月と共にあるものなのである。
やはり太陰暦に戻すしかないのである。

やっぱ、ユダヤ歴がいいね。

西暦も元号もやめて、明治以前の十干十二支にしよう

もう、皇紀と西暦でいいじゃん
その内、宇宙暦とかでてくんだろ？

>>76
宇宙世紀ダブルオー・セブンティナインとかあれですか

>>76
皇紀は年月を遡る形で定義されているので確実性が... 今後の研究の成果等で修正も?

どうやら今より1年が短かった時代があるようで。魏志倭人伝で当時の倭人の寿命が
80〜90歳とか最初の方の天皇の在位が異常に長いとかの話もそれで説明可能とか。

しかし零戦とかはどうなっちゃんだw

めんどくさいから安倍でいいや

>>78
西暦0年生まれじゃないらしいな、キリスト

>>80
お前まじか

キリストは日本で復活した

西暦0年とか存在しないから生まれようがないわなｗ

今だから言えるが西暦は0から始めた方が良かったな
当時の人間には先見の明がまったく無かったと言えよう

いや別にどうでもいい

数字の0の発見は5世紀のインドなので仕方ない

西暦一年の一年前って何年なん？

>>87
macOSのカレンダーによると大化-644年ですね

紀元前1年だろ

天文学では西暦0年

いつ対応するんですか？

ガラパゴス元号なんて、天王星と一緒に即廃止！

天文学では西暦使いにくいのでJulian date使う西暦紀元前4713年が原点。
シュメール文明の最初とかエジプト古王朝の初めとだいたい一致するが、特に意味は考えてはいけない。

13月カレンダーか。

>>46
Windowsはすでにレジストリに定義が付加されてる。
文字コード(合字)が決まったらそこにアプデパッチで対応。

合字って、ユニコードで元号が1文字になってるやつのこと? （平成 -> U+337Bとか）
場所はもうU+32FFに予約されてるみたいだけど。
今後フォント的にその情報を足さないといけないのか。あとユニコードの正規化情報も。

U+32FFって、◯ + ヲの後のかろうじて一つだけ空いてた場所に無理やり突っ込んだ感は否めないw
ここらへんの記号の類の場所は既にギチギチで、数十年以内に次の元号が来るはずだが、
その時はどうしようもなさそう。もうBMPから外れてもいいかもしれんけど。
あるいはその頃にはユニコードも違うものになってたりするだろうか。

そういうのは合字とは言わない

そうですか、初耳です。よろしければなぜ合字と呼んではいけないのかと。

合字じゃないから

>>99
合字だからお前はもう黙ってろな

Unicode「合字」使う企業は修正が必要に、日本マイクロソフトが新元号対応
https://tech.nikkeibp.co.jp/it/atcl/column/14/090100053/120500290/

>>96
> 今後フォント的にその情報を足さないといけないのか。あとユニコードの正規化情報も。

どうせUnicodeは毎年のようの文字が増えてる

あとBMP内の日本語の領域でも空きはあちこちあるだろ
そんな都合よくぴったり収まってるわけないんだし

�合紫順~㋿

文字バケバケバケバケ乙

> Unicode
毎年バンバン増える絵文字に対応する手間に比べたら
実際のところ一文字増やす手間くらいどうってこともない

新元号をいちいちフォントに追加するのか！とか騒いでる人いるけど
年号の合成文字より絵文字の方が使用頻度としては明らかに少ないからね
そういうことをいう人はまずは絵文字について問題視する方がいい
実際少数民族の言語ほったらかしで絵文字が先かよ！という批判もある
あるけど、ならそう思うヤツがとっとと提案しろやってのがコンソーシアム的対応

>>100
お前は日経のそんな記事を真に受けてるのかｗ

>>105
日経の記事に間違ってる所があるの？

だから U+337B とかは 「リガチャ（合字）」 ではないんだよ
>>100の記事を書いてる田中 陽菜ってのも合字が何なのかわかってないんだろうな

>>106
間違っているというか
カギ括弧つきで「合字」と書いてあるように本来の意味ではないってことでしょう
ただ読者には説明としてわかりやすいからね

>>107
さんのこだわりもわかるがアドビも合字と表現したプレスリリースを出した
https://www.adobe.com/jp/news-room/news/201904/20190401-adobe-newera.html

まあリガチャはリガチャであって日本語の合字とは違うぜっていわれそうだが

NKFDで正規化すると�~が平成になるから一応Unicode的には合字扱いなんじゃないかな
学問的には合字って言うと本来は麿みたいなやつを言うんだろうけど

NSString *str = @"\u337b";
NSLog(@"%@,%@",str,[str decomposedStringWithCompatibilityMapping]);

広義の合字(�盾ﾆか�_も含む)と狭義の合字(Unicodeのリガチャ)をごっちゃにしてマウントしあって虚しくねぇか？w

もう一度言うけど U+337B とかは 「リガチャ（合字）」 ではないんだよ
>>108の記事を書いてるアドビってのも合字が何なのかわかってないんだろうな

Windowsだと○○1年は元年と表示できるみたいね。macOSは単に1年だったかと。ちょっと負けてるw

macOSのカレンダーで遊んでみたが、年表示の場合1989年は単に昭和64年となるのね。
日数的には平成だし、さらにいえば昭和64年/平成元年 などと表示すべきかなと。
理論上2つ以上の元号もありうるんでそういうコードにするということでw

>>112
OSXのロケールはNEXTSTEP由来だったのでかなり頑張ってた方で
旧OS9に比べるとちゃんとしててスゲーなと思っていたのもつかの間
アップルがさぼっている(かどうか知らないが)うちにWindowsに抜かれた

https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_5_beta_2_release_notes

>Support for the Reiwa (令和) era of the Japanese calendar, which begins on May 1, 2019, is now available.
>The first year of Japanese-calendar era is represented as “元年” (“Gannen”) instead of “1年”, except in the
>shorter numeric-style formats which typically also use the narrow era name; for example: “R1/05/01”. (27323929)

令和も元年対応もICU由来なんでしょ多分。新しいICUを移植しましたって書けばいいのにw

でもあれか、ライブラリ的にちゃんとインターフェースを出してなかったり、あくまでも内部のこと、
ということになってるのか。MeCabなんかと同じで。さすがApple様w

>>114
結局このアップデートは令和になるまでに出るのかな? そしてMojave以外は?
もしかして現在中の人が最終チェック中?

とりあえずMacの日付設定を和暦にして待つとするかw

>>112
Windows OS本体の初期値は"1年"　→　レジストリの変更により"元年"に設定可能
.NET Frameworkの初期値は"元年"

ユーザーの憶測では4/10のWindows Updateで対応すると思っていたが未対応
MSのコメントでは連休前(4/26)には対応したい遅れるかもと言っていたが
明日に配信されるようには思えない

どうでもええけど、元号なんて使うことあるの？

Windowsはレジスリにキー追加するだけで対応可能
アプリはまた別の話
アプリの件はmacOSやiOSも同様というかxcodeが対応しないとというレベルで
もっとひどいよw

>>117
まあ、所詮、連休前に対応してくれるかもっていうのは
日本政府の希望的観測ですからねｗ

MSの方をチラチラみながら、ほら前倒ししたよ？
対応してくれるよね？ね？っていっても
MSからすりゃ、そんな約束してないし知らんがな。なんだろうねｗ

ぶっちゃけ遅れてトラブルになってほしい。
そうすりゃシステム対策には時間がかかるって
馬鹿にも理解できるやろ

既にMSはやらかしているという
https://qiita.com/ht_deko/items/249db60e1c99ba440969

ここにも反日が
https://www.bbc.com/news/av/world-asia-46026910/japan-s-princess-ayako-surrenders-her-royal-title

>>119
Xcodeは古いままでも問題ないから。しかるべきコードを書いてれば自動的に新元号に対応する。

ベータ版のiOSとmacOSで令和って表示できたよ。
コード書いてベータ版のiOS入れたiPhoneでも問題なしだった。

セキュリティホール残したままで新API対応不可
あまつさえしてAppStoreでの利用禁止なのに何言ってんだw

日本語おかしいですよ

OSの新元号対応より日本語変換の新元号対応して
→ATOKは4/18に対応済み

>>126
単に単語登録すればいいと思うが。

細かいことを言うと、macOSの日本語変換だと変換候補の意味表示を更新したりする必要が
あるのか。

令和 -> 年号（2019年5月1日〜）。今上天皇の時代。
平成 -> 年号（1989年1月8日〜2019年4月30日）。...の時代。

おっとっと、この最後の部分は?
もう最終的な称号がどうなるかは決まってるんだっけ? 今までの経緯からすると平成天皇に
なりそうだが... そのタイミングって? もしかして崩御後? とりあえずは太上天皇?

平成院じゃないの？

>>127
>単に単語登録

それだと、「あした」「きのう」で変換できない

macOSのアップデート、きたね

>>128
平成は諡号になる予定なので、今はまだ使えない。
上皇殿下だっけ？

アイゴー

>>131
上皇「陛下」

どうでもええけど、元号なんて使うことあるの？

なんてことを言うんだ。不経済で逮捕されるぞ！

真・スレッドストッパー。。。(￣ー￣)ﾆﾔﾘｯ