Javaバージョン別の改元(新元号)対応まとめ - Qiita
はじめに 改元が2019年5月1日、新元号が「令和」と4月1日に発表されました。新元号の発表が1ヵ月前の4月1日に予定されています (4/1見直し) 関連する記事は「Javaで新元号に対応する」などがありますが、Java SE 8(以下、単にJava 8のように表記)からのDate and Time APIに対応していなかったり、それ以外のブログなどでも古い情報が多いため、改めてなるべく網羅的かつ実践的となるよう、まとめてみることにしました。 ※本記事は改元対応が完了するであろう2019年5月くらいまでは随時更新する予定です。 誤りや補足などあれば適宜コメントなどでご指摘ください。 (3/24追記) 2019年3月21日(米国時間)にOracle社のブログ記事「A new (Japanese) era for Java!」(日本語翻訳)が公開され、2019年4月16日(米国時間)に予定され
18分59秒をめぐって日本標準時の歴史をひもとくことに - エムスリーテックブログ
この記事は エムスリー Advent Calendar 2018 12日目の記事です。 こんにちは。エムスリー エンジニアリンググループの三浦(@yuba)です。基盤開発チームというところで各サービスチーム共用のシステムの開発保守に携わっており、そこで見つけた面白い動作を掘っていったら意外な知識にたどり着いたという話をいたします。 化けた日付はどこから来た？ あるサービスの管理画面の動作を検証していたときのことです。バリデーションの振る舞いを確かめるためにいくつかテストケースを作りながら実際の動きを試していたところ、不思議な現象を見つけました。 次のように日時入力をするところで年の欄を空のままにして送信したところ⋯ 次のようにおかしな日時が設定されたのです。 0013年？ 18分59秒？ 入力した覚えのない数字が3つも紛れ込んでいます。 これが C で書かれたプログラムなら何か不定値を拾っ
サマータイムで日本中の電波時計がゴミになる(かも)という話 – mzsm.me
先日、安倍首相が2時間時刻を進めるサマータイムの導入検討を自民党に指示したという報道がありました。 実は、このサマータイムが導入されると、我々の生活に身近なある物をすべて買い換えなければならなくなるかもしれません。 というか既にタイトルでネタバレしているのですが、そのある物とは、電波時計です。 定期的に自動で時刻を合わせてくれるため、手動で時刻を合わせる手間がなく大変便利な時計なのですが、実は、現行の電波時計では現在検討が進められている2時間のサマータイムには対応できないのです。 電波時計の仕組み 電波時計は、「情報通信研究機構（略称：NICT）」という国の機関が送信している「JJY」という無線局の電波を受信して正確な時刻を取得します。 NICTは「日本標準時」を決定・維持している、まさに日本の時を司っている機関です。 何年かに一度行われる「うるう秒」の挿入のとき、大きなデジタル時計の前で
コンピュータシステムのサマータイム対応を巡る二つの楽観論 - アンカテ
いきなり来年から日本でサマータイムを導入するという話が出てきて、私には到底実現できない話としか思えなかったが、自民党の少なくとも一部の方々は本気で考えているようだ。そもそも、私にはメリットがどこにあるのかわからないがそれは置いておいて、コンピュータシステム側の対応が非常に困難であるということを、なるべく一般の方にわかるように説明してみたいと思う。 5chとツィッターを眺めて見ると、同業者の人は私と同じ意見が多数であるように見えるが、一部楽観的に見ている方もいるのに驚いた。何事にもいろいろな見方があるので、賛否両論の意見があって議論していけばいいことではあるが、その楽観論を見ていると、全く違う立場の二種類の楽観論がある。何がなんでも自分の立場が正しいと主張する気はないが、この二種類の楽観論が絶対両立しないことは確かで、ここだけはハッキリしておかなければならないと強く言いたい。 最悪のケースは
UTC-0:44 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "UTC-0:44" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2022年12月） UTC-0:44とは、協定世界時を44分遅らせた標準時である。1972年5月1日までリベリアでモンロビア標準時（リベリア時間）として使用された。 1919年3月1日にUTC-0:44として再定義されるまでは、GMT-0h43m08sが標準時とされていた。 1972年以降は、リベリアがGMTを標準時として使用するようになったため、現在、UTC-0:44を使用している国・地域は存在しない。 UTC-0:44 0 1 2 3 4 5 6 7 8 9 10 11
【大日本帝国の国土】戦前日本の標準時 - Man On a Mission
前回、戦前日本の領土や委任統治領など、太平洋戦争以前の日本の統治領域について書きました。 oplern.hatenablog.com 今回記事はその補足。戦前日本における標準時について。補足記事につき、短めの記事となっております。 現在の日本標準時 現在の日本では、協定世界時（UTC） を基準に9時間進めた時刻が日本標準時（JST）として用いられています。 プラス9時間というのは東経135度分の時差に相当（UTC+9）します。UTCの前身である「グリニッジ平均時（GMT）」にて知られる、グリニッジ天文台・グリニッジ子午線が経度0度となりますが、ここから東経135度地点では9時間進んでいるということになりますので、経度15度の違いで1時間の時差が発生するわけですね。 さて、今の日本では北海道から沖縄まで、全国一律の標準時となっていますが、前回触れたとおり、戦前の日本、大日本帝国では統治領域が
ぼくたちのかんがえたさいきょうのi18n国家
本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一瞬で滅びそう — Masaki Hara (@qnighy) 2018年8月6日 長い前置き ソフトウェアのi18nは難しい。自文化では当たり前と思っていてハードコードしてしまった仮定が崩れて、大幅な再設計を余儀なくされるからだ。気づいて再設計できればまだ良
tz database - Wikipedia
Time Zone Database（元々[4]はtz database[5]と呼ばれていた）とは、IANAが管理している、世界各地域の標準時や常用時の時間帯（time zone、タイムゾーン）情報を収録したデータベースである。主にコンピュータ・プログラムやオペレーティングシステムでの利用を意図している[6]。tz、tzdb[7]、tzdata、zoneinfo databaseなどとも呼ばれる。 元々は、アーサー・デイヴィッド・オルソン（Arthur David Olson）が開始したプロジェクトであり、1980年代より複数のボランティアにより更新され続けていた[8]。その事にちなみOlson databaseとも呼ばれる[9]。2011年10月14日よりICANNのIANAが管理することとなった[8]。ポール・エッガート（Paul Eggert）と Tim Parenti が現在のTi
ThreeTen BackportのInstant.plus(long, TemporalUnit)は年を足せない - Takuji->find;
Androiderならきっとみんな大好きなはずのThreeTen Backportに関しての雑メモ。 今から100年後のInstantが欲しくなって Instant.now().plus(100, ChronoUnit.YEARS) ってやってみたけど UnsupportedTemporalTypeException で死んだ。 コードを読んでみると ChronoUnit.YEARS はサポートされていなくて以下の ChronoUnit しか使えなかった。 NANOS MICROS MILLIS SECONDS HOURS HALF_DAYS DAYS 月と年の計算は曖昧な部分(うるう年とか)があるからサポートできないのだろうか。 とりあえず厳格に100年後が欲しかったわけじゃないので plus(36500, ChronoUnit.DAYS) でなんとかすることにした。 問題のコードはこの
時差/経度/緯度 前説
使い方 該当する場所の時差がプラスの場合は出生時間にそのまま足します。 時差がマイナスの場合は出生時間からそのまま引きます。 パソコンの占いソフトやネット上のホロスコープ作成サービスを利用する時は、 経度と緯度を使います。 命式（四柱推命）・命盤（紫微斗数）なら、経度だけを使います。 記載例 E141°21′N43°04′＝東経141度21分、北緯43度04分 ※ただし、分以下を小数点表示に直す必要がある場合もあります。 （東経135度15分なら、15÷60＝0.25 なので、東経135.25度となる） 作成ノート 時差は、30秒未満を切り捨て、それ以上を切り上げしてます。 時差を求める公式は、（出生地の経度－135）×４（分） です。 明石市より西にある場合はマイナスの数値になります 経度/緯度は、30秒未満を切り捨て、それ以上を切り上げし、度分までの表示としました。 経度/緯度は、各市
タイムゾーン呪いの書 - Qiita
コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa
Java日付時刻フォーマッターメモ(Hishidama's Java8 DateTimeFormatter Memo)
概要 [/2017-07-26] 生成 整形（format） 解析・解決（parse） [/2014-07-23] SimpleDateFormatとの違い [2014-07-23] 書式の文字 [2014-07-23] リゾルバースタイル [/2014-07-23] 解析フェーズのみの実行 [2014-07-28] 概要 日付時刻オブジェクトを文字列に整形（format）、あるいは逆に文字列から日付時刻オブジェクトを生成（parse）するにはjava.time.format.DateTimeFormatterを使う。 （従来はjava.text.SimpleDateFormatを使っていた） DateTimeFormatterは不変オブジェクトであり、スレッドセーフである。 ただし、シリアライズ可能ではない。（SimpleDateFormatはシリアライズ可能だったが）[2017-07-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ThreeTen-Backport error on Android - ZoneRulesException: No time-zone data files registered
礼文島（北海道） - ヒトコト図鑑
私のまわりのおバカさん(38)
もんじゃの２１世紀なつやすみ（９／１３）
DateTimeFormatter (ThreeTen backport 1.6.8 API)
Java 8 - Convert LocalDate to ZonedDateTime
Java Date to UTC using gson
Compute Week of Year issues with ZonedDateTime and Calendar API