はてなキーワード: 閏年とは
——————————————————————————————
告
5/15
「科学哲学第二」のレポートは、5/31 までに1号館1階の浅川の レターボックスに提出すること。
——————————————————————————————
告
6/3
期限を過ぎて提出されたレポートは、いかなる理由があろうとも 受けつけません。
締切を過ぎてもまだ私のレターボックスに「科 学哲学第二」のレポートを入れる者が居ますが、5/31 の午後 5:00 以降に投函されたレポートは全て破棄しました。
——————————————————————————————
告
6/4
「5/31 まで」と書いたら「5/31 の午後 5:00 まで」の意味です。
こんなことは社会常識です。
——————————————————————————————
告
6/5
他の教官が午後 12:00 まで受けつけていても、関係ありません。
反例を幾つ挙げようと、定量的に述べなければ意味がありません。
——————————————————————————————
告
6/8
なぜその熱意を使い、もっと早くにレポートを作成しないのか理 解に苦しみますが、とりあえず午後 12:00 まで受けつける教官が 過半数であることは理解しました。
よって、6/15 の午後 12:00 まで「科学哲学第二」のレポート提出期限を延長します。
——————————————————————————————
告
6/10
「6/15 午後 12:00 まで」ではなく「6/16 に浅川がレターボック スを開けるまで」ではないか、との意見がありましたが、これら は全く違います。必ず 6/15 中に提出するように。
——————————————————————————————
告
6/12
私のレターボックスに猫の死骸を入れたのは誰ですか。
——————————————————————————————
告
6/13
「私がレターボックスを開けた瞬間に波動関数が収束し、内部状 態が定まるので、レターボックスを開けるまではレポートが提出 されたかどうか分からない」と主張したいことは分かりました。
今回は、提出場所を1号館302の浅川研究室前のレポート提出 用ボックスにします。
この箱は、6/15 午後 12:00 にシュレッダー へと自動的に切り換わるので、シュレーディンガーの猫の問題は発生しません。
——————————————————————————————
告
6/16
いいかげんにしなさい。午後 12:00 は「グリニッジ標準時」では なく「日本標準時」です。
普段は日本時間で生活しているくせに、レポート提出時だけグリ ニッジ時間を求めるなど言語道断です。
——————————————————————————————
告
6/18
信じ難いことですが、「科学哲学第二」を受講する学生の過半数 がグリニッジ標準時で生活していることが分かりました。
夜型にも程があるとは思いますが、とりあえずレポートの提出は6/30 の午後 12:00 GMT まで待ちます。
——————————————————————————————
告
6/22
時間の連続性についての疑義は受けつけません。どうやらベルグソン の時間論を曲解している者がいるようですが、主観的時間がどうあれ、 7/1 の後に 6/30 が来ることはありません。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
「それで、確かに君は 6/30 中にレポートを提出したというんだね?」
「ええ、ギリギリでした」
「だが、君のレポートは私の手元には無い。君は時間を間違えたのではないかな?」
「いいえ、日に 0.1 秒も狂わない、正確な電波時計を使っていますから。
先生のレポートボックスこそ、時刻を間違えたんじゃないですか?」
「冗談だろう。GPS 補正で ±5 ミリ秒の精度で合わせてある」
「それで、24:00 GMT ちょうどにシュレッダーに切り換わるわけですね?」
「そうだ」
「うーーん。あ、そうだ。多分うるう秒の差ですね」
「うるう秒?」
これは太陽の公転周期から計算する平均太陽時と違い、原子時計によって
計られることになっています。この協定世界時と実際の天文時刻との
差を縮めるため、12/31 や 6/30 などの午後 24:00:00 に、閏年の2月29日
と同様の 1 秒を挿入することがあるんです。いやあ、このうるう秒の
間に僕はレポートを提出して、先生のシュレッダーが動作したんですね。
言語によっては標準的に月末日を取得できる関数が用意されている
用意されてない場合もそこそこあるし
サードパーティー的なライブラリだとライセンスなどメンテナンス含めて面倒になるので避けることも多い
そもそも仕様を「月末日」などという不確定なものにせずに28日にしてもらう
ちゃんと仕様を決める部門と連携が取れていれば多くの場合で28日にしてくれるし
「28日支払い」が多いのもこのためだと思ってる
割とよくある実装がこの「次の月初めから1日(1秒)引く」という実装
2024年2月の月末日を取得する場合は2024年3月1日のUNIX時間から24*60*60秒を引いて計算する
ただし、実装を間違えると12月31日のときに失敗するので注意が必要
各月の月末日をマップとして保持しておいて取得させる
関数実装するなら if(month==1) return 31 とかを12行書けば実装できる
自分で実装する場合はプログラミングの教科書にあるぐらい有名なのでコピペでもChatGPTでも使えば良い
ただ仕様をそのまま実装せずに「4で割り切れたら閏年」でも問題無い(やったことはないが)
「それだと2100年でバグる!」
ちなみに過去の日付であっても2000年はバグらない(そのための400年処理だし)ため
色々開発に携わってきたが大体2パターンある
Case month when 1 then ~って感じのコード。thenの後にif文や更にCase文がある。この辺りに28日までとか書いてある。
ソースレビューがあったら指摘する内容だが機能していない場合はこのレベルが来る。オフショアで海外に出すとマジでこんなの書いてくる。指摘するとはいはい言うけどどうすれば良いのか悩む。
アーキテクチャ次第だが単に29までに変更すれば良い場合もあるが、たまに他にも影響したりして結構絶望する。月末日取得で書いてたら説教レベル
大体Case文パターンでロジックが考えられない場合国内外が提案してくるのがマスタ化だ。発注元も何故か柔軟な対応が出来るからと賛成してくる
結果年1や月1のマスタ設定が必要になり運悪いタイミングで担当者が閏年を忘れてると大体起きる。賛成した人らは運用しないので気楽だ。
こっちはマスタ設定すれば良いのだが、閏年ですよ忘れていませんかチェックは無いくせに登録出来るのは翌日以降チェックはしっかり入ってたりする。
設計段階で考慮すれば良いのだがマスタは何故か新人の仕事となり結果糞仕様にスキル不足が重なって復旧に時間がかかったりする。もちろん新人に罪は無い。日付をキーにするマスタなんて要件で考えた奴が悪い
閏年に影響されない業務やフローにする。そもそも年月日を指定するか2/28の次は3/1だと明示しない限りはシステムは閏年でバグを起こさない。
もし日付チェックを自作の変なロジックで作って発生させてたら20代なら許すが30代以上は即引退して他の仕事探したほうが良い。変に生き残って上流に行くと出来上がるのは意味の分からない事を言うステークホルダーという老害で将来はコンサルとか名乗って中小零細で惨めなシステム論を語る粗大ゴミだ
プログラミングを一通り教えても
って言って作れない人が多い
ということに気付かない人が非常に多い
何を言っているか分からないかもしれないが本当にこれを理解してくれない人が多い
「閏年は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で割り切れたらとりあえず閏年なんだな」
ということに気付けるかどうかが真の課題で、実際に業務でコードを書くときもその手の整理が非常に重要になる
顧客や課題やバグをそのまま受け取ってそのまま修正しようとすると一生直らないか非常に苦労する
この事象は要するにどういうことか、というのをベン図なり状態遷移図なりで整理するところが重要でコーディングはそれを実現するテクニックにすぎない
情報系を出ていない新入社員は知らないだけの可能性があるので教えれば使い物になる可能性もあるが
SES(システムエンジニアリングサービス)とは、システムエンジニアを派遣する形態の一つで、多くは月の稼働時間に対して、システムエンジニアを派遣する会社に支払われるお金が変わる。
大体、8時間×20日 で 月160時間を標準として、その前後20時間は通常通り支払う。
上回ったらその分多く払い、下回ったらその分減額される。
システムエンジニアの多くは会社から140時間は下回るなと仰せつかっている。
システムエンジニアリングサービスは収益は多く働くか人を増やすかしないとあげることはできない。
少なく働くことは年度の目標を下回る主な原因になる。
システムエンジニアの人々が時給感覚で働いているのはそのためだ。
人が少なく炎上している現場であれば、160時間は余裕で越えて、180時間も余裕で越えて、会社に貢献できる。
一方で雇用問題に理解のあるホワイトなプロパーと、保守期間に入って平和な時間が訪れた現場、
特に定時で帰って144時間にしかならない2月はハードモードだ
炎上が終わって、平和な時間が訪れたタイミングでちょっとお休みとって遊びに行きたい。
今年だったらまさに今日休みを取って4連休にして遊びに行くとか(今年はコロナの事情で無理だが)そういうことがしたいが
プロパーの人は、お休みとっていいよといっても、あなたがたの偉い人は僕らの契約形態を変えてはくれないのだ…
むしろ、風邪を引いたとか雪が降って会社に行けないとかがあるかもしれないと考慮して、2月の頭に無駄な残業をして残機を稼ぐみたいなこともしてしまう。
大きい反応は3パターン。
1.「なに考えてんの?やめろよ」
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日に再生。
東京事変はライブを開催へ チケットの払い戻しも実施 #正しい行動!林檎!さすが。命かけて演奏し命かけて聞きに行く。生活に必要な音楽。日常を新たにするもの。なくてはならないもの。今この日でなければならない出来事。— 井上 道義 (@daibutsumichiko) February 29, 2020
そう思われても仕方ないと思います。
というか私は思いました。
「じゃあ仮に、2012年に解散せず、毎年ツアーやってたら今回決行してたか?」
と考えたら、「決行してないんじゃないかなあ」と思ってしまいます。
はっきり「中止・延期・縮小して欲しいです」になっている状況です。
令和2年2月20日
新型コロナウイルスの感染の拡大を防ぐためには、今が重要な時期であり、国民や事業主の皆様方のご協力をお願いいたします。
最新の感染の発生状況を踏まえると、例えば屋内などで、お互いの距離が十分にとれない状況で一定時間いることが、感染のリスクを高めるとされています。
イベント等の主催者においては、感染拡大の防止という観点から、感染の広がり、会場の状況等を踏まえ、開催の必要性を改めて検討していただくようお願いします。なお、イベント等の開催については、現時点で政府として一律の自粛要請を行うものではありません。
令和2年2月26日(安倍総理)
政府といたしましては、この1、2週間が感染拡大防止に極めて重要であることを踏まえ、多数の方が集まるような全国的なスポーツ、文化イベント等については、大規模な感染リスクがあることを勘案し、今後2週間は、中止、延期又は規模縮小等の対応を要請することといたします。
こうした状況において、
中止という決断は、
「コロナ怖いからライブ行かなかった。でも、行けばよかったなあ…」と葛藤するだろうし、
ごめんなさい。泣く泣くライブ断念することにします。本当に辛い決断でしたが、やっぱり大切な家族や友達を感染させてしまうリスクは冒せないというのが私の答えです。本当に大好きな東京事変。もう二度と見れないかも知れないのは重々承知です。死ぬ程行きたかったけど今は守るべきものを優先します。— コケシ (@01__incidents) February 27, 2020
東京事変Live開催について母と口論になったが、こんな状況であっても
演るべき理由が東京事変にはある事をこのバンドの人生を知らない人には
到底理解し難いのだろうと即断し、
以降、静観でいる事にした。
8年ぶりの復活、閏年、閏日。他のバンドには皆無な要素だろ?この日じゃなきゃ意味がない。— Yeuxbruns (@hito_mazu) March 1, 2020
「なんで行ったんだ」「ふざけんな」と
家族・同僚・友人などから、バッシングの嵐になることは目に見える。
これが返金対応だと「なにが何でも行ってやる」という人も
「行けばよかった…」という人も増えてしまう。
返金対応があった。
それも素晴らしい対応だけれど、
ファンも残念だけどすっきりするんです。
妄想の域を出ませんが
オトナの事情なのかもしれません。
それは間違いないから、仕方ないのかもしれません。
でもだとしても、
そういうアーティストたちが実際にいたし、
彼らがすごくかっこよく見えてしまいました。
@numbergirl_jp
本日、3/1(日)Zepp Tokyoにて開催を予定しておりました公演に関しまして、新型コロナウィルス感染拡大を防ぐため公演延期とさせていただきますが、「無観客状態」でのライブ生配信、ライブビューイングは予定通り行います。
BAD HOP
@badhop_official
BAD HOPからのお知らせ。
この度、コロナウイルスの影響により3月1日に予定していた横浜アリーナの公演を中止とさせて頂きます事を深くお詫び申し上げます。
@sukima_official
2020年2月28日(金)19時より無観客ライブ生配信を実施することとなりました。
ツアーと同じ内容ではありませんが、千秋楽公演を楽しみにされていたお客様、
並びに日頃よりスキマスイッチを応援頂いている皆様へ音楽で貢献できたらという想いで実施致します。
詳細はこちらをご覧ください。
http://office-augusta.com/sukimaswitch/live/index.html#notice20200227
@TGCnews
【重要なお知らせ】
2/29(土)の『マイナビ TGC 20 S/S』ですが、新型コロナウィルスの感染拡大を受け、無観客開催となりました。
東京ディズニーランドおよび東京ディズニーシーは、「新型コロナウイルス感染症対策本部」からの「多数の方が集まるような全国的なスポーツ、文化イベント等については、大規模な感染リスクがあることを勘案し、今後2週間は、中止、延期又は規模縮小等の対応を要請する」という発表を受け、2020年2月29日(土)から3月15日(日)の間、臨時休園することを決定しましたのでお知らせいたします。
再開日につきましては、3月16日(月)を予定しておりますが、関係行政機関等と密に連絡をとり、あらためてお知らせする予定です。
ロックとはなにか
なんて私には語る資格もないですが、彼らの姿勢はロックだなと思いました。
その範囲の中で楽しむことができる。
ロックがかっこいいのかもしれません。
もし今回、東京事変が5000人の会場で、無観客ライブを配信していたら・・・
最高にクールな、歴史に残る復活劇だっただろうと思うと、いちファンとして(勝手に)残念です。
好きだけどね。
〜〜〜追記〜〜〜
「皆が自粛する中ライブやってロックだね!」というファンに対して
それは違くない?という話でした。
ロックを語りたいのではなく