「閏年」を含む日記 RSS

はてなキーワード: 閏年とは

2024-03-01

月末日の取得方法

ライブラリにある標準的実装使用する

言語によっては標準的に月末日を取得できる関数が用意されている

それを使うのが一番簡単バグが出ないが

用意されてない場合もそこそこあるし

サードパーティー的なライブラリだとライセンスなどメンテナンス含めて面倒になるので避けることも多い

月末日にせずに28日にする

そもそも仕様を「月末日」などという不確定なものにせずに28日にしてもらう

どの月にも28日はあるので問題無い

ちゃん仕様を決める部門連携が取れていれば多くの場合28日にしてくれるし

28日支払い」が多いのもこのためだと思ってる

翌月マイナス1日で計算する

割とよくある実装がこの「次の月初めから1日(1秒)引く」という実装

2024年2月の月末日を取得する場合2024年3月1日UNIX時間から24*60*60秒を引いて計算する

ただし、実装を間違えると12月31日ときに失敗するので注意が必要

自分実装する

各月の月末日をマップとして保持しておいて取得させる

関数実装するなら if(month==1) return 31 とかを12行書けば実装できる

この場合閏年考慮していないと4年に一度バグが発生する

閏年の判定はライブラリ標準的実装されていることが多いが

自分実装する場合プログラミング教科書にあるぐらい有名なのでコピペでもChatGPTでも使えば良い

ただ仕様をそのまま実装せずに「4で割り切れたら閏年」でも問題無い(やったことはないが)

「それだと2100年でバグる!」

などと騒ぐやつがUNIX時間を使ってるのはなかなか興味深い

ちなみに過去の日付であっても2000年バグらない(そのための400年処理だし)ため

1900年を入れない限りは問題無い

最高齢の人でも1900年からなので基本的には問題無いだろう

たまにプルダウンで1901年からしか入れられないシステムを見るが、「もしかして閏年のせい?」と思ってる

2024-02-29

閏年バグ理由

色々開発に携わってきたが大体2パターンある

Caseパターン

Case month when 1 then ~って感じのコード。thenの後にif文や更にCase文がある。この辺りに28日までとか書いてある。

ソースレビューがあったら指摘する内容だが機能していない場合はこのレベルが来る。オフショア海外に出すとマジでこんなの書いてくる。指摘するとはいはい言うけどどうすれば良いのか悩む。

アーキテクチャ次第だが単に29までに変更すれば良い場合もあるが、たまに他にも影響したりして結構絶望する。月末日取得で書いてたら説教レベル

スタパターン

大体Caseパターンロジックが考えられない場合国内外提案してくるのがマスタ化だ。発注元も何故か柔軟な対応が出来るからと賛成してくる

結果年1や月1のマスタ設定が必要になり運悪いタイミング担当者閏年を忘れてると大体起きる。賛成した人らは運用しないので気楽だ。

こっちはマスタ設定すれば良いのだが、閏年ですよ忘れていませんかチェックは無いくせに登録出来るのは翌日以降チェックはしっかり入ってたりする。

設計段階で考慮すれば良いのだがマスタは何故か新人仕事となり結果糞仕様スキル不足が重なって復旧に時間がかかったりする。もちろん新人に罪は無い。日付をキーにするマスタなんて要件で考えた奴が悪い

閏年バグ回避方法

閏年に影響されない業務フローにする。そもそも年月日を指定するか2/28の次は3/1だと明示しない限りはシステム閏年バグを起こさない。

日付チェックで存在しない日付と閏年チェックは基本だ。

もし日付チェックを自作の変なロジックで作って発生させてたら20代なら許すが30代以上は即引退して他の仕事探したほうが良い。変に生き残って上流に行くと出来上がるのは意味の分からない事を言うステークホルダーという老害で将来はコンサルとか名乗って中小零細で惨めなシステム論を語る粗大ゴミ

ワイ閏年誕生日、4年ぶりの誕生日にむせび泣く

お前ら祝ってくれ

2023-12-18

来年は117年ぶりに1月1日月曜日になる年らしい

閏年の影響で次の1月1日月曜日になる年は2104年

2023-09-09

蓬莱学園よりも今のインターネットの方が凄いと思う

プレイヤー数は億単位、作り込みは超リアル

稼働時間24時間365日完全不眠不休(*閏年閏秒を含む)。

実際の経済軍事にさえも影響力を及ぼすことが可能で、賞罰もリアルマネーで行われることが少なくない。

圧倒的な作り込みとリアルへの地続き感ながら、虚実織り交ぜる実力があれば誰でも何者にもなれるし別人に成り代わることも可能

驚異的な自由度の高さと方向の見えなさ。

プレイヤーによる自主的ゲーム非公式イベントも日夜開催されておりむしろそっちがメインコンテンツと言える。

大型プレイヤーによる大規模活動は人々に強烈な影響力を与え、それを受け他の大型プレイヤーが大きく介入することで自体は更なるカオスに。

なぜPBMが滅びたのか。

それはインターネットのものが最も巨大なPBMとなってしまたからに他ならない。

2023-05-02

[] そのろっぴゃくごじゅう

アタナシウーッス

 

本日日本において八十八夜緑茶の日、郵便貯金の日、交通広告の日歯科医師記念日となっております

先日も八十八夜緑茶の日を書いてしまいましたが、アレは閏年の時に日が増えてしまってそれで前日にズレているものとなります

から、どちらかといえば今日の方が今年の八十八夜緑茶の日となっております

日程の意識はとても大事ですね。

気をつけておきましょう。

 

ということで本日は【日時の確認いか】でいきたいと思います

日時の確認いか!日時の確認ヨシ!

 

それでは今日も一日、ご安全に!

2023-05-01

[] そのろっぴゃくよんじゅうきゅう

マグヌーッス

 

本日メーデー日本においては八十八夜緑茶の日すずらんの日、日本赤十字社創立記念日、扇の日、水俣病啓発の日となっております

メーデーです、労働者権利行使して〜の日ですね。

給料とか色々待遇が良くなればいいんですけどね。

何か変わったとしても黒澤映画の生きるみたいになりそうですね。

ともあれ、そういう積み重ねを大事にして、日々改善をしていくようにしましょう。

 

八十八夜緑茶の日は閏年の時に採用されるもので、例年は五月二日になっております

 

ということで本日は【日々改善いか】でいきたいと思います

日々改善いか!日々改善ヨシ!

 

それでは今日も一日、ご安全に!

2023-02-23

anond:20230223072758

そうか2月末を超えると閏年があるから揺れが生じるんだな。やるな元増

2023-02-16

anond:20230216073157

さらに今年は閏年ではないか28日までしかないんだね!短っ!

他の月は30日、31日まであるのに2月28、29日までしかなくてアンバランス過ぎる。

もう改暦できないのかな。

2022-11-10

人類が滅びたらやり直したいこと3選

一ヶ月が30日だったり31日だったり28日だったりゴミみたいなカレンダーを全人類が使ってるとか信じられない

そもそも12ヶ月である必要性はないのだ

28日13ヶ月にすれば364日になる

残り1日は0日(ゼロデイ)として1年の始まりを祝えばいい

閏年最後にΩ日を作ってオメガデイとして4年間に思いをはせればよい

28日にすることで毎月1日は日曜日になるし日付と曜日が紐付くのでカレンダーがいらなくなる

今日は15日の日曜日だね」

とかどの月でも通用する

円周率

円周率が「直径」に対する円周の比率になっているせいでいろんな弊害がある

「半径」に対する比率でいいのだ

まり2πがπでいいのだ

かの有名なe^iπ = -1 も e^iπ = 1になってもっと美しくなる

まぁ、τとかを提唱してる人はいるが知ってる人は居なかろう

電流の向き

まぁ、後は電流の向きかなぁ

2022-10-30

そもそもプログラミングをするための学力がない

プログラミングを一通り教えても

「じゃぁ閏年判定プログラムを作りましょう」

って言って作れない人が多い

最初ハードルは余りの計算をするところで

余りの計算方法は分かっていても

閏年は4で割り切れるから余りが0になれば閏年なんだ」

ということに気付かない人が非常に多い

何を言っているかからいかもしれないが本当にこれを理解してくれない人が多い

閏年は4で割り切れるんだよ」と「yearを4で割った余りが0になると閏年」には非常に大きな壁があると思っていい

そしてこのハードルを越えても

「4で割り切れる年は閏年ですが100で割り切れると平年です。ただし400で割り切れると閏年です」

という、このハードルを越えられる人は本当に一握りしかいない

仮に乗り越えたという人が現れても

if ( year % 4 == 0) {
  if ( year % 100 == 0) {
    if ( year % 400 == 0) {
      return true;
    } else {
      return false;
    }
  } else {
    return true;
} else {
  return false;
}   

みたいなクソコードしか書いてこない

ちゃんと整理すれば

if ( year % 400 == 0) return true;
if ( year % 100 == 0) return false;
if ( year % 4 == 0) return true;
return false;

と、これだけで書けるというのが分かる

これは実は引っ掛け問題になっている

最初に「4で割り切れると閏年」というところから設問が始まってるので、その通りに実装するとあっという間にスパゲティになる

「要するに400で割り切れたらとりあえず閏年なんだな」

ということに気付けるかどうかが真の課題で、実際に業務コードを書くときもその手の整理が非常に重要になる

顧客課題バグをそのまま受け取ってそのまま修正しようとすると一生直らないか非常に苦労する

この事象は要するにどういうことか、というのをベン図なり状態遷移図なりで整理するところが重要コーディングはそれを実現するテクニックにすぎない

情報系を出ていない新入社員は知らないだけの可能性があるので教えれば使い物になる可能性もあるが

情報系を出ているのにこの手の整理ができない新入社員はもう育成しないししても無駄だということが分かった

要するに学力全然足りてないのだ

プログラミングスクールなんかに通う前にしっかりと学力を身につけてくれないか

2022-08-20

「売る動き」って「閏年」みてえだな

そうすると

うるう+ごき ゴキになるんだよ

音声だけだと紛らわしいっす

2021-05-28

暦の理解

カレンダー日付で、毎月月末が30日とか31日とか異なること、あまり気にしてなくて毎年変動していると思ってた。

7/30 までの年もあれば、7/31 までの年もあるんじゃないかと。

30歳手前にして、あれ、これは毎年固定なんじゃないかと。閏年部分は別として、他の月の日数は固定なんじゃないかと閃いたわけです。

ユリイカカレンダー確認して叫んだね。

2021-04-07

anond:20210407010504

オリンピックは4年に一度で、閏年の周期と重なる

閏年2月は29日まである、って話じゃない

なんか色々ずれてるけど

2021-02-22

転職し、SESじゃない嬉しさを嚙み締める2月

2月、令和になって休日が多くなった閏年じゃない2月

SESシステムエンジニアリングサービス)とは、システムエンジニア派遣する形態の一つで、多くは月の稼働時間に対して、システムエンジニア派遣する会社に支払われるお金が変わる。

大体、8時間×20日 で 月160時間を標準として、その前後20時間は通常通り支払う。

上回ったらその分多く払い、下回ったらその分減額される。

システムエンジニアの多くは会社から140時間は下回るなと仰せつかっている。

システムエンジニアリングサービス収益は多く働くか人を増やすかしないとあげることはできない。

少なく働くことは年度の目標を下回る主な原因になる。

システムエンジニアの人々が時給感覚で働いているのはそのためだ。

人が少なく炎上している現場であれば、160時間は余裕で越えて、180時間も余裕で越えて、会社に貢献できる。

一方で雇用問題理解のあるホワイトプロパーと、保守期間に入って平和時間が訪れた現場

一般的に恵まれ環境場合SESは困ってしまう。

特に定時で帰って144時間しかならない2月ハードモード

炎上が終わって、平和時間が訪れたタイミングちょっと休みとって遊びに行きたい。

今年だったらまさに今日休みを取って4連休にして遊びに行くとか(今年はコロナ事情で無理だが)そういうことがしたいが

この140時間の縛りで遊びに行くととは不可能だ。

プロパーの人は、お休みとっていいよといっても、あなたがたの偉い人は僕らの契約形態を変えてはくれないのだ…

しろ風邪を引いたとか雪が降って会社に行けないとかがあるかもしれないと考慮して、2月の頭に無駄残業をして残機を稼ぐみたいなこともしてしまう。

だが、SESではない業態会社転職をした。

もうこんなことでカレンダー時間計算する必要などないのだ。

2021-01-09

干支カレーを入れろ

十二支だとあまり予定調和的なので、ひとつくらいバランスを乱す要素が欲しい

人気と意外性を兼ね備えたものといえば何だろうか?カレーでしょう

閏年だけカレー年になるみたいなシステムOK

2020-05-27

anond:20200527164400

目の前のブラウザを使って、例えば「今日の日付を入れたら閏年かどうかを計算する奴」を作ってみては?

そんなちゃちな物でも楽しめるなら、希望はあるかもね。

2020-03-01

ロック迷惑紙一重東京事変ライブコロナウイルス

東京事変ライブが決行されました。

大きい反応は3パターン

1.「なに考えてんの?やめろよ」

2.「さすが東京事変ロックだ!」

3.「好きだったけどがっかり。嫌いになった」

私自身は「あ、やるんだ」くらいのお粗末な感覚だったのですが、

時間が経つにつれて、”ある考え”が大きくなってきました。

 

それは、ロック迷惑紙一重だということ。

今回のライブ決行は、ロックではなく迷惑だということ。

そして、

夢を売る仕事は、時に誰よりもリアリストであらねばならない、ということです。

 

私は東京事変ファンであり、椎名林檎のことも好きです。

今回のライブチケットを応募してたし、

決行を知って、最初したことチケットリセール探しでした。

 

コロナウイルスは過度に怖がられすぎだと思っていたからです。

致死率3%程度。

本場中国でも感染者7万9251人に対して、死者2835人 です。

https://www3.nhk.or.jp/news/html/20200229/k10012307571000.html

武漢市のある湖北省を除いたら、致死率は約0.16%という報道があります

これはインフルエンザの致死率の2倍程度。

https://premium.toyokeizai.net/articles/-/22953

武漢市の致死率が高いのは、

医療チームのクオリティや、病院のベッド数の不足が関係している、とされています

https://premium.toyokeizai.net/articles/-/22953

 

実際のところは誰もわからないので割愛します。

でも東京事変ライブやろうが、やらなかろうが

山手線満員電車に乗っている私にとっては

大して変わらないだろうな、というのが正直なところです。

 

そんな楽観的な私が、

「だとしても今回のライブロックパンクではなく、迷惑」と思う理由は、

東京事変ライブ決行の理由にあります

 

あくまで推測(妄想)の域を出ませんが・・・

閏年だったから決行したんでしょ?」という思いが拭えません。

 

2012年2月29日に解散

そして8年ぶり、

2020年2月29日に再生

このように閏年閏日

東京事変にとって重要意味を持っています

 

ストーリーとしては綺麗ですが・・・

ファンの命より大事なことか?」

そう思われても仕方ないと思います

というか私は思いました。

 

妄想だと言われたらそこまでだし、実際妄想なんですが、

「じゃあ仮に、2012年に解散せず、毎年ツアーやってたら今回決行してたか?」

と考えたら、「決行してないんじゃないかなあ」と思ってしまます

 

政府が1〜2週間のイベント自粛要請を出しています

もともとの「判断はおまかせします」から

はっきり「中止・延期・縮小して欲しいです」になっている状況です。

イベントの開催に関する国民の皆様へのメッセージ

令和2年2月20日

 新型コロナウイルス感染の拡大を防ぐためには、今が重要な時期であり、国民事業主の皆様方のご協力をお願いいたします。 

 最新の感染の発生状況を踏まえると、例えば屋内などで、お互いの距離が十分にとれない状況で一定時間いることが、感染リスクを高めるとされています

 イベント等の主催者においては、感染拡大の防止という観点から感染の広がり、会場の状況等を踏まえ、開催の必要性を改めて検討していただくようお願いします。なお、イベント等の開催については、現時点で政府として一律の自粛要請を行うものではありません。

令和2年2月26日(安倍総理

政府といたしましては、この1、2週間が感染拡大防止に極めて重要であることを踏まえ、多数の方が集まるような全国的スポーツ文化イベント等については、大規模な感染リスクがあることを勘案し、今後2週間は、中止、延期又は規模縮小等の対応要請することといたします。

この判断が遅かったかどうかはおいておいて、

自粛要請が出されているのは事実です。

 

そして学校が一斉休校している。

こうした状況において、

イベントの多くは中止、または延期になっています

 

 

中止という決断は、

ファン本人への感染を防ぐということも勿論ですが

ファンの周りの人達への感染、それによるトラブルも防ぎます

 

ファンは当たったら行きたいに決まっています

コロナいかライブ行かなかった。でも、行けばよかったなあ…」と葛藤するだろうし、

無理に行こうとして家族や友人とケンカになる可能性もある。

 

行ったら行ったで、ライブから感染者が出たら

「なんで行ったんだ」「ふざけんな」と

家族・同僚・友人などからバッシングの嵐になることは目に見える。

まり、中止はファンを色々な意味で守っています

 

これが返金対応だと「なにが何でも行ってやる」という人も

「行けばよかった…」という人も増えてしまう。

チケットリセールがあった。

返金対応があった。

それも素晴らしい対応だけれど、

そもそも中止になったほうが感染拡大も防げるし、

ファンも残念だけどすっきりするんです。

 

妄想の域を出ませんが

もし仮に、本当に閏年にこだわって決行したのだとしたら・・・

40歳をすぎて、子供のいる母でもある椎名林檎が、

そんな子供っぽい判断をしたのだとしたら・・・

ロックではなく迷惑だと言わざるを得ません。

 

ライブ決行の理由は、実際のところわからないです。

オトナの事情なのかもしれません。

膨大なお金時間がかかっている。

それは間違いないから、仕方ないのかもしれません。

 

でもだとしても、

オトナの事情に逆らって、なんとかして、ファンを大切にする。

そういうアーティストたちが実際にいたし、

彼らがすごくかっこよく見えてしまいました。

 

NUMBER GIRL

@numbergirl_jp

本日、3/1(日)Zepp Tokyoにて開催を予定しておりました公演に関しまして、新型コロナウィルス感染拡大を防ぐため公演延期とさせていただきますが、「無観客状態」でのライブ配信ライブビューイングは予定通り行います

詳細は公式サイト・狂う目でご確認下さい。

http://numbergirl.com

 

BAD HOP

@badhop_official

BAD HOPからのお知らせ。

この度、コロナウイルスの影響により3月1日に予定していた横浜アリーナの公演を中止とさせて頂きます事を深くお詫び申し上げます

ですが、無観客状態で本番同様の内容でBAD HOPのYouTubeアカウントにてライブの生配信を決定しました。

詳細は添付画像をご確認ください。

 

スキマスイッチ公式

@sukima_official

■2/28(金)無観客ライブ配信実施について

スキマスイッチツアースタッフ一同協議を重ね

2020年2月28日(金)19時より無観客ライブ配信実施することとなりました。

ツアーと同じ内容ではありませんが、千秋楽公演を楽しみにされていたお客様

並びに日頃よりスキマスイッチ応援頂いている皆様へ音楽で貢献できたらという想いで実施します。

詳細はこちらをご覧ください。

http://office-augusta.com/sukimaswitch/live/index.html#notice20200227

 

東京ガールズコレクションTGC

@TGCnews

重要なお知らせ】

2/29(土)の『マイナビ TGC 20 S/S』ですが、新型コロナウィルス感染拡大を受け、無観客開催となりました。

当日は、TGC公式LINEにて生中継をいたします。

チケットの払い戻しにつきまして追って公式サイトにてご案内いたします。

理解ご協力をよろしくお願いいたします。

 

東京ディズニーランドおよび東京ディズニーシーは、「新型コロナウイルス感染対策本部からの「多数の方が集まるような全国的スポーツ文化イベント等については、大規模な感染リスクがあることを勘案し、今後2週間は、中止、延期又は規模縮小等の対応要請する」という発表を受け、2020年2月29日(土)から3月15日(日)の間、臨時休園することを決定しましたのでお知らせいたします。

再開日につきましては、3月16日(月)を予定しておりますが、関係行政機関等と密に連絡をとり、あらためてお知らせする予定です。

 

 

ロックとはなにか

なんて私には語る資格もないですが、彼らの姿勢ロックだなと思いました。

 

普段は、同調圧力にケリを入れる。日常を忘れさせてくれる。

でも「迷惑迷惑じゃないか」の線引きはしっかりできていて、

その範囲の中で楽しむことができる。

 

観客も、演者も、その一線を引けるから

ロックがかっこいいのかもしれません。

 

もし今回、東京事変が5000人の会場で、無観客ライブ配信していたら・・・

最高にクールな、歴史に残る復活劇だっただろうと思うと、いちファンとして(勝手に)残念です。

好きだけどね。

 

〜〜〜追記〜〜〜

「皆が自粛する中ライブやってロックだね!」というファンに対して

それは違くない?という話でした。

ロックを語りたいのではなく

2019-10-04

anond:20191004205020

ほぇぇ

なるほど、ありがとうごさいます

ぴったり一周できずに1年が終わるから閏年閏秒で補ってるんですね。

1秒の長さを決めているのも地球太陽関係ですか??

2019-04-29

西暦4年から

元号バグを聞いて「日付をシリアル値で管理して出力後に変換テーブルを噛ませばいいんじゃないの?」って思ったんだ。

でも銀行だったら昔のデータもあろうから使えないって気付いたので、「じゃあもっとから起算すればいいのでは?」と思ったので作ってみた

西暦十干十二支十干漢字十二支漢字連番何巡目?グレゴリオ暦閏年判定グレゴリオ暦によるシリアル
41111閏年1
52221平年367
63331平年732
74441平年1097
85551閏年1462
96661平年1828
107771平年2193
118881平年2558
129991閏年2923
131010101平年3289
14111111平年3654
15212121平年4019
1631131閏年4384
1742141平年4750
1853151平年5115
1964161平年5480
2075171閏年5845
2186181平年6211
2297191平年6576
23108201平年6941
2419211閏年7306
25210221平年7672
26311231平年8037
27412241平年8402
2851251閏年8767
2962261平年9133
3073271平年9498
3184281平年9863
3295291閏年10228
33106301平年10594
3417311平年10959
3528321平年11324
3639331閏年11689
37410341平年12055
38511351平年12420
39612361平年12785
4071371閏年13150
4182381平年13516
4293391平年13881
43104401平年14246
4415411閏年14611
4526421平年14977
4637431平年15342
4748441平年15707
4859451閏年16072
49610461平年16438
50711471平年16803
51812481平年17168
5291491閏年17533
53102501平年17899
5413511平年18264
5524521平年18629
5635531閏年18994
5746541平年19360
5857551平年19725
5968561平年20090
6079571閏年20455
61810581平年20821
62911591平年21186
631012601平年21551
641112閏年21916
652222平年22282
663332平年22647
674442平年23012
685552閏年23377
696662平年23743
707772平年24108
718882平年24473
729992閏年24838
731010102平年25204
74111112平年25569
75212122平年25934
7631132閏年26299
7742142平年26665
7853152平年27030
7964162平年27395
8075172閏年27760
8186182平年28126
8297192平年28491
83108202平年28856
8419212閏年29221
85210222平年29587
86311232平年29952
87412242平年30317
8851252閏年30682
8962262平年31048
9073272平年31413
9184282平年31778
9295292閏年32143
93106302平年32509
9417312平年32874
9528322平年33239
9639332閏年33604
97410342平年33970
98511352平年34335
99612362平年34700
10071372百年おきの平年35065
10182382平年35430
10293392平年35795
103104402平年36160
10415412閏年36525
10526422平年36891
10637432平年37256
10748442平年37621
10859452閏年37986
109610462平年38352
110711472平年38717
111812482平年39082
11291492閏年39447
113102502平年39813
11413512平年40178
11524522平年40543
11635532閏年40908
11746542平年41274
11857552平年41639
11968562平年42004
181810583平年64650
182911593平年65015
1831012603平年65380
1841114閏年65745
1852224平年66111
1863334平年66476
1874444平年66841
1885554閏年67206
1896664平年67572
1907774平年67937
1918884平年68302
1929994閏年68667
1931010104平年69033
194111114平年69398
195212124平年69763
19631134閏年70128
19742144平年70494
19853154平年70859
19964164平年71224
2000751734四百年おきの閏年729025
2001861834平年729391
2002971934平年729756
20031082034平年730121
2004192134閏年730486
20052102234平年730852
20063112334平年731217
20074122434平年731582
2008512534閏年731947
2009622634平年732313
2010732734平年732678
2011842834平年733043
2012952934閏年733408
20131063034平年733774
2014173134平年734139
2015283234平年734504
2016393334閏年734869
20174103434平年735235
20185113534平年735600
20196123634平年735965
2020713734閏年736330
2021823834平年736696
2022933934平年737061
20231044034平年737426
2024154134閏年737791
2025264234平年738157
2026374334平年738522
2027484434平年738887
2028594534閏年739252
20296104634平年739618
20307114734平年739983
205077735平年747288
おぼえがき
ログイン ユーザー登録
ようこそ ゲスト さん