macOSは新元号に対応するんですかね?情報が無いよ
■ このスレッドは過去ログ倉庫に格納されています
あのさ、Apple。東方の小さな島国の年号だからって軽く見てやしませんかね? >>2
そうじゃねーよ。いきなり未知の年号が登場したら
アプリが困るだろうが。
4/1公表の4/11実施だぞ。10日しかない。
Appleの対応を含めりゃアプリが検証・対応する時間は数日しかないだろ
なにがどう変わるのか、事前に検証するにはどうすれば良いのか?
その方法を提供しろって 訂正 4/1公表の5/1実施だぞ。1ヶ月しかない
(4/11は元々の公表する日だったみたい) システム環境設定→日付と時刻→暦法の設定によってはいろいろな日付が和暦で表示されるから
表示だけならあらゆるアプリが影響を受けるよ
動作に影響するの可能性があるのはNSDateFormatterで和暦を解釈する場合とかかな
まあアップデートが来るでしょ 元号なんざ、ガラパゴスの極致。めんどくさいし、非合理的だし、いい機会だから即刻廃止願います。 新元号対応がギリギリまで遅れるのはAppleなどソフト会社のせいではなく
新元号をギリギリまでどこにも公表しない安倍政権・自民党と
改元当日まで新元号を公表するなと主張してる日本会議・神道政治連盟が元凶 よっぽどアホな作りしてなきゃ数行書けば対応できるはず >>10
> 新元号対応がギリギリまで遅れるのはAppleなどソフト会社のせいではなく
いや、方針とか発表しろよw
Windowsはレジストリにキー追加するだけで対応出来るようになってるから
今から新元号が追加された想定でテストできるんだぞ
ついでにいうと、本当は4/11に公表だったのが、Microsoftがそれじゃ間に合わねーよって
言ったから4/1に公表が前倒しになった。Microsoftの影響力はすごいや >>13
macOSとWindowsの普及率考えればまぁ当然だろうな MSすごいって言いたいだけの人だったか…。
レジストリ対応ってなんか危なっかしいな。まあ仮対応みたいなもんだろうが。 >>17
レジストリは駄目って言いたいだけの人ですか?
レジストリが駄目ならファイルに保存するのもだめなんでしょうねw >>17
MSがすごいじゃなくて
Appleはいったい何やってんだよ!って言いたい人なんじゃないか 流石にソースコードレベルではすぐ対応できるようにしてあると思うけどね。
レジストリはさすがに永遠にそのままはダメでしょw だからなんでレジストリでは駄目なんだ?
そんなことを言ってるとmacOSや他OSで同等のやり方を
やっていることがわかった時、お前恥をかくだけだぞ。
理由を言っておけって。 保存すること自体はどっかにしなきゃならんけど、なぜよりにもよってレジストリみたいな比較的不安定な場所?という疑問はある。
過去の元号なんて変わりようがないのに、消したり書き換えたりが容易な場所に保存する意味ってあんの?
よく言えば柔軟性のある仕組みにしてある割に明治以降しか対応してないようだし。 レジストリがなにか特殊なものだとでも思ってるの?
実体は単なるファイルなんだけど。
プログラムだって実体は単なるファイル > 過去の元号なんて変わりようがないのに、消したり書き換えたりが容易な場所に保存する意味ってあんの?
バイナリだってバイナリエディタで書き換え可能だし macOSの和暦実装はおそらくICUに依存してて
ICUの方は既に対応が済んでいる(今の所新元号はQQになっている)から
どこかのタイミングでアップデートされるんでないの
https://github.com/unicode-org/icu/pull/111 ICUの実装としては/usr/share/icu以下にバイナリデータがあってそれを参照していると思われる 問題は、Macが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ぐらいだろw レジストリ壊れたことある?
自分でいじって壊したことすらないんで意外と丈夫なイメージだが >>36
レジストリが壊れたー。Windowsはクソ
フリーズしたー。Windowsはクソ
起動しなくなったー。Windowsはクソ
HDDも壊れたー。WindowsがHDDを壊した
って言ってる間抜けなら見たことがあるw 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日 新元号検証ラボと新元号に関するセミナー開催予定のご案内 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デコーダ搭載か macOSのカレンダーで少し遊んでみた。
あれ、日本が太陰暦だった頃のずれが正しく考慮されてないような。
例えば明治の始まった日、慶応でいうと4年9月8日は西暦1868年10月23日のはずだが
暦のフォーマットを和暦からグレゴリオ暦に変えると1868年9月8日になる。 MacOSって19世紀のカレンダーにシステムレベルで対応したことあったっけ? 4で割って100で割ってってあのルールを緩和するために1904年(うろ覚え)スタートにしたとかって奴かな
おかげで2000年問題が生じないとかなんとか
前世紀の遺物については当然記憶も定かではないw >>56
>>55のような日付データの扱いに関して、動作を見ると「対応してない」というべきかと。
でも表示だけは明治はおろか無駄に大化とかも出せるんだよなー
例えば純真な学生がMacのカレンダーを使って「本能寺の変は天正10年6月2日か。メモっとこう」
みたいなことをやったら間違い。ってしないかw
ま、ICU自体がその辺はあまりちゃんとしてないみたいなので、それを受け継いでるのかな。
こんなのはとっくに対応してるのかと思ってた。 和暦と西暦変換が必要な表計算ソフト位が影響あるんじゃないの?
Microsoft社は一般公開前に教えてくれと日本政府に言ってあるんじゃないかね?
新元号も漢字2文字なんだろうし、UNICODEに無い漢字は使わないでしょう
三国志くらいにしか出てこない人名漢字なんて使わないw >>61
すでに別の用途で一般的に使われてる単語にはしないよ ググれっていうのは、言葉を知らんお前に対してだよ
俺は知ってるからググっていない >>1
元号なんて廃止でいいだろ
何年前か即座に分からなくて困るから不便極まりない キリストの誕生年さえわからなくなる西暦を廃止した方が良いぞよw 人類は未だに「月」という暦の単位から離れられない。
すなわち人類とは月と共にあるものなのである。
やはり太陰暦に戻すしかないのである。 もう、皇紀と西暦でいいじゃん
その内、宇宙暦とかでてくんだろ? >>76
宇宙世紀ダブルオー・セブンティナインとかあれですか >>76
皇紀は年月を遡る形で定義されているので確実性が... 今後の研究の成果等で修正も?
どうやら今より1年が短かった時代があるようで。魏志倭人伝で当時の倭人の寿命が
80〜90歳とか最初の方の天皇の在位が異常に長いとかの話もそれで説明可能とか。
しかし零戦とかはどうなっちゃんだw >>78
西暦0年生まれじゃないらしいな、キリスト 今だから言えるが西暦は0から始めた方が良かったな
当時の人間には先見の明がまったく無かったと言えよう ■ このスレッドは過去ログ倉庫に格納されています