エンジニアの大橋 @_tohashi です。会計freeeで確定申告や記帳機能などの開発を担当しています。 Webに限らず、日本向けのアプリケーションにおける特有の要素として和暦があります。プロダクトによっては最初から和暦を扱わずに西暦に統一してしまうという手もありますが、弊社のプロダクトのように会計や労務管理に関わるものの場合、決算書上の表記など和暦が必要とされる場面は多々あるため避けて通ることはできません。本記事ではUIや実装における和暦の扱いについてご紹介したいと思います。 和暦の範囲 そもそも「和暦」とはどこからどこまでの期間を指すのでしょうか。Wikipediaによれば 和暦（われき）は、元号とそれに続く年数によって年を表現する、日本独自の紀年法である。邦暦（ほうれき）とも。また「和暦」は、西暦に対する表現としても使用されることが多い。 この手法自体は東アジアで広く行われてきたが
ちょっとまじめにRubyと天文計算の勉強したくなったので、いっぺんにやってみることにした。 これはあくまで勉強用の覚書です。 Rubyで書かれた天文計算のライブラリが欲しいという人は、友野大悟さんのruby-sphereを使ってください*1。 Contents Julian Day : ユリウス日 Sidereal Time : 恒星時(グリニッジ平均恒星時/地方恒星時) Delta-T : Delta-T (TDT-UT) Development environment Jornada 710 Debian Serge/720degree (Linux version 2.4.32-j720) Ruby 1.8.5 (2006-08-25)[arm-linux] Reference Jean Meeus "Astronomical Algorithms" Willmann-Bell, I
日本は今年西暦2018年（平成30年）を迎えましたが、来年には元号が変わると話題になっています。 先日、QR Translatorのコンテンツを制作していると、「クーポンの有効期限は2018年までです。」というテキストがありました。日本語の他にも英語や簡体字、繁体字や韓国語などの多言語展開をしていた為、他の言語を見比べていると、なんとタイ語だけ数字部分が「2561」になっていました！ タイ語だけ年号の数字部分に誤りがあったのかと思い、念の為調べてみたところ、タイには「タイ太陽暦」といった独自の換算方法が用いられていることが分かりました。 日本でも西暦とは別に和暦（現在は「平成」）が使われていますが、他の国でも独自の表示が使われていることがあるようです。 元号（げんごう）は、特定の年代に年を単位として付けられる称号である。年号（ねんごう）とも呼ばれることもあるが、元号のみならず、紀年法の名称
前回の記事「Excelだけに存在する日付」では、Excelにだけ存在する、実在しない日付形式について書きました。 今回も日付つながりで、データベースの日付時刻型の話を書きたいと思います。 ほとんどのデータベースは、日付時刻型を持っています。 ところが日付時刻型は、数値型や文字型のようにどのデータベースでもほぼ共通、ということはなく、利用可能な範囲、分解能（秒、ミリ秒、マイクロ秒など…）から内部のデータの持ち方まで、データベースや型によって様々です（「範囲」が決まっているのは、日付時刻型に限りませんが）。 日付時刻型の内部値は、前回お伝えしたとおり「ある特定の日付を基準に、その日付からの経過日数で表す」ものがほとんどかと思います。 前回は「経過日数」と書きましたが、データベースによっては「経過秒数」だったり、現在のOracle Databaseのように全く異なる内部管理を行っている例もあった
ネットサーフィンしていたところ、『東京五輪終わっても「サマータイム」恒久的運用へ』(スポーツ報知、2018年8月8日)という記事に、面白いことが書いてあるのを見つけた。 ◆夏時間への切り替え方 導入初日を4月の最初の日曜日とした場合は午前2時に2時間進め午前4時に合わせる。夏時間が始まる日曜日は1日が22時間になる。10月最後の日曜日をサマータイムが終わる日とした場合は午前4時に2時間戻し午前2時に合わせる。この日は1日が26時間となる。 いや、それは、かなりマズイことになると思う。現在の日本の法令は、そのほとんどが「一日」を「二十四時間」だと仮定していて、しかも、同じ時刻が二度存在しないことを、大前提としているからだ。たとえば、戸籍法施行規則第二十一条第七号。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
