はてなキーワード: タイムスタンプとは
ガラケーのカレンダーがおかしくなったって話題になったけど、他に周囲で観測できてるやつをメモっとく。
古いバッファローのNAS(LS-WXL等)で2020/1/1から内蔵時計が2000年になってしまう問題。
定時メンテナンスが毎時走る、ネットワークレコーダでのDTCP-IP録画ができない、ファイルのタイムスタンプがおかしくなる等のトラブルが発生している。
一旦NTP(自動時計合わせ)の利用をやめてマニュアルで時計を合わせる(もしくはPCと同期)と改善する。
いわゆるTS抜きチューナ用の録画アプリで、かなり前から脆弱性が報告されていながらもメンテナンスされていないが利用者はそれなりにいるかと思う。
女性でまぁ、典型的な毒女なんだけど仕事はピカイチに出来て。俺もこの業界長いけど「なんでそんな発想が出来るわけ?」ってアイデアをいつも出す人だった。
そんで無類のゲーム好きだった。
部署が変わって、スマホのRPGゲームを始めて、職場でそのゲームをやっている人達のグループLINEに参加したらメンバーの一人が元上司だった。
立場的に気は使ったけど、LINE上では至って普通のゲームオタクって感じで、いつもきゃっきゃしてた。
正直まだ信じられない。だってグループLINE開いたら、昨晩のタイムスタンプで彼女のメッセージがある。
(私はもっぱらROM専)、なんなら今もLINEを開けば彼女のトーク履歴が山のように出てくる。
亡くなったって話を聞いた後、グループLINE上から急遽友達追加して「○○さーん」とだけ、送ってみた。
そんな彼女にメッセージを送っても、もう二度と既読になる事は無い。
「あ、あれ。面倒だからただ既読スルーしてるだけですよね?。今日はもう寝たんでしょ? 明日朝になれば既読つくよね?」って正直今も思ってる。
あの可愛いアイコンが謎のURLを貼りつけてきたり、スタンプを貼りつけてくる事はもうないんだ。
「抜けたー(クリアしたの意)」って言葉が非常に印象的だったが、そんな言葉ももう聞くことはない。
ああ。人が死ぬってこういう事なんだな。次があるかも次があるかも、ってずっと思ってきたけど。
その次はある日突然寸断される。この年になって初めて知った。 そしてそれが死ぬ事なんだと思った。
30数年生きてきて、人の死をここまで身近に感じたのは初めてかもしれない。
父親が脳の病気で死にかけた事があったが、それよりも近くに死を感じている。
つらつらっと書きなぐるとこんな状況。
同じグループライン上で「重大発表」とか「悲報」なんてスタンプ使って、他人の死を伝えるのはどうなんだと。
もうちょっとさ。「すごく言いにくいことなんですが・・・」みたいな入り方とか。枕詞はいくらでもあっただろ。なんでこんな時にあんなチープなスタンプなんだよ。
なんつーか、小学生が「○○くんと○○ちゃんが遊んでましたー。ひゅーひゅー。報告報告ー」って冷やかしで言うのと大して変わんない。
その重大発表と悲報スタンプは、他人の死を伝える為に使うスタンプじゃない。
何か書いていてだんだん悲しくなってきた。
でも、正直彼女に感情移入していても何か自分の人生が進展する訳ではないので、会社のメンバーには「悲しいよね」って言いつつ、仕事をこなす事にする。
まぁ、1週間もしたら忘れるだろ。
今までありがとうございました。
K察「ブクマカさん。これは全員に聞いてるので気になさらないで欲しいのですが、事件当時の昨夜22時頃、あなたは何をしていましたか?」
K察「SNS的な活動...TwitterとかInstagramですか?」
ブクマカ「いえ、昨夜はいい大喜利も思いつかなかったのでひたすら他人のブコメを読んでました」
K察「大喜利?」
K察「星?」
K察「フォローした相手の良いと思った投稿につけるんですよね?」
K察「互助会?」
K察「ええと、仲間内でいいね!をつけあって盛り上がったりとかではないんですか」
ブクマカ「そうですね。どちらかというと殺伐とした感じで手斧を投げ合ってるというか」
K察「手斧?」
K察「分かりました。とにかくあなたは事件当時、SNS的サイトで他人の投稿に評価をつけていた。そうですね」
ブクマカ「だいたいそうです」
K察「とすると、評価をつけた履歴が分単位で記録されていればアリバイになる可能性があります」
ブクマカ「ああ、それならhttp://s.hatena.ne.jp/ユーザー名/starsで確認できます」
K察「どれ...」
K察「それはこちらで問合せます。どのあたりが事件当時のものですか?」
ブクマカ「この辺ですかね」
K察「ちょっと見方が独特ですね。この左に表示されているアイコン、これは手斧ですか?」
ブクマカ「どうでしょうね。Twitterのような個人のアカウントにアイコンが付けられて、それが並んでます。私が星を付けた相手の一覧です」
ブクマカ「...」
K察「もう一度見方を教えてもらえますか?この辺からずっと同じアイコンが並んでますけど」
ブクマカ「...」
K察「ブクマカさん?」
ブクマカ「...」
K察「見ず知らずの相手って話でしたが、お友達か誰かのアイコンということですかね」
K察「ブクマカさん?」
ブクマカ「お気に入りのブクマカなんです。いえ、お気に入りには入れてないんですけど、いつも面白い投稿をするんで、ついついブコメ一覧をのぞいてしまって」
K察「」
ブクマカ「別に、星をつけて自分を認識して欲しいとかそういうつもりでもなくて」
K察「」
意識高い系のいかにも仕事できなそうで職場や案件たらいまわしにされてるの丸わかりの増田とか、使えなさ過ぎて業界から追い出されてシコシコ技術ブログとか書いてるんだろうなっていう元ITエンジニアって肩書のブロガーとか自称業界人の皆様たちのおかげで、絶賛20代30代がいなくなり、40代50代の脳みそ壊れたオッサンオバサンばかりと少子高齢化のあおりを受けまくってるIT業界
そんな彼らが「IT業界がダメになったのは国や社会の責任だ!」と鼻息荒く早口でよく責任転嫁をしているが、彼らに「じゃあ昔のIT業界ってどんな風な仕事の仕方だったの?」っていっても口が裂けても答えてくれないことが多いのは周知の事実だと思う
だから、これから運悪く新卒でブラックにあたって職歴に傷がついているからIT業界に仕方がなく来るしかない、という第二新卒の方々や、IT業界に来たいんだ!という奇特な新卒やダ学生の増田向けに、まだ日本がITでは世界2位だったころは、どんな風な仕事の仕方だったのかを、知ってほしいからこれをかこうと思う。
増田が大好きで大好きで仕方がないweb系も、始まったのは実は92年くらいからで、その当時のweb系も合わせてどういう仕事なのかを知ったうえで、貴重な若い人生を無駄にしないように将来を考えてほしいと思う。
例えば業務用ツールの案件の場合、顧客はIT知識やましてやシステムのことなんて何も知らない
だからコンサルが「客の職場に常駐して」まず業務のヒアリングから始めていた
今でこそコンサルなんて半グレやヤクザみたいなのが業界の4割くらいしめていて詐欺師の代名詞みたいになっているが、当時はそんなことはなくちゃんとした技術者も多く、故に顧客がコンサルにまで正当にお金を払う文化が存在していた、この時点で信じられないとか発狂する増田もいるだろうが、真実なので落ち着いてほしい。
顧客は自分の会社ではあるけど現場でどんな業務が行われているかが見えてないケースさえ昔は多かった
まず業務手順の整理や確認をして行く、「SEとセールスエンジニアが常駐して」ヒアリングと現状の手作業の事務の工数をはじきだしていく。
今でこそセールスエンジニアとか茶飲みに来た営業の横にくっついている愛想悪そうなオッサンがやる気なさげに右上のタイムスタンプ数年前の資料かえただけのものをバサっと投げつけて技術わかってない客を見下しまくって喧嘩を売ってるような態度のエンジニア上がりとかが業界のセールスエンジニアの6割を占めているが、当時はそんなことなく、ちゃんとした一般常識や教養や礼儀や共感性が人並みにある健常者の技術者上がりも多く、故に顧客が常駐しているセールスエンジニアに正当にお金を払う文化が存在していた、この時点で嘘だ!主語がデカい!とか発狂する増田もいるだろうが、真実なので落ち着いてほしい。
現場の運用が把握して業務の棚卸しが始まる、無駄な業務を実施していることがここで判明してくる
だから、業務で発生している課題がハッキリして来る、システム移管時に何の業務が対象になるかが判って来る。
現状の客の業務ワークフローをドキュメント化して客に示して行き、詳細な機能要求仕様書も起こして行く。
今でこそIT業界のエンジニアたちが口をそろえて「それは客がすべきことだろ」と震え声でわなわなしながらブツクサ、ICT知らん奴は人にあらずみたいな商売と人様を舐め腐ったことを言うことも多いが、昔は顧客には本業の仕事だけに注力をして貰いたいのがベンダーとしての考えだったわけだ。これはwebサービスとか自社サでやるweb系の始祖であるところとかも一緒
課題が顕在化して来ると今後起こりうる可能性のある課題まで浮かび上がってくる、そして要求要件が固まると客にコストの提案が始まる
今までの業務コストとシステム化やシステム改修によるコストの差を示して行き、構築見積もりもここで概算を提示する。
概算見積もりの段階で高いと言う客にはここで終わりにはなってしまう。
OKなら、ここまでの見積もりコストを人権費と経費を基に計算して15%乗っけて完了、ドキュメント類は報告書として残して行く。
「なんでドキュメント類なんて残していくんだよ!ICTを知らん猿如きに!!!」って発狂するIT業界の現状の人間も甥が、理由はこれによって「顧客は競争入札が可能になるから」という至極まっとうなビジネスとしての理由がある。
こういうの今はBtoGでもめったにやらないだろうけど、大体すべてIT業界ではこれくらいが当たり前だった。増田が邪教の如く忌み嫌うウォーターフォールって奴だ(省庁は年度を跨ぐと手続き面倒だからデ通サが多いけどね)
さて、ここまで詰めてくれるわけだから、下流側は昔はコーディング設計書さえあった時代、マシンの性能以外を除けば、プログラマーとしてはこれほど助かることもない、綺麗なコーディングに注力できるから、だから昔の日本人プログラマーのコーディングは、芸術レベルで美しかったといわれる理由がこういう仕事の仕方が昔は当たり前だったからだ
昔のアメリカ以外で太刀打ちできる国は地球上に存在しないとまで言われていた時代の日本のIT業界を支えたSEやエンジニアたちは、ここまでやりがいのある仕事をする。
そりゃ年収一本当たり前だわな、これだけできれば。
今のIT業界の仕事の回し方なんて、アジャイル至上主義のweb系とかも見てもらえばわかるが、昔と比べればもはや学園祭の焼きそば屋レベル
上記のような仕事をされると困るから、そういうのが憎くて憎くて仕方がないみたいな奴らしかいないIT業界に、それでも来たいというのならどうぞご自由に。
え?海外いく?行けるわけないでしょコネもないのに。夢みたいなこといってないでパソコンの前に座るような不健全な仕事しないで汗をかいて働きなさい。
その嘘がどうして無理があるかと言うと
最初の「書いてないじゃん」
https://anond.hatelabo.jp/20190514125825
は12:58
https://anond.hatelabo.jp/20190514125953
は12:59
それを即2人目が読んで突っ込めたと?
ありえないな
2016年7月13日19:41に下記のツイートがされている。
これがトリックだと仮定すると、すぐに思いつくのは、投稿日時をあとから書き換えるハックだと思う。
いくつかの解説記事によると、id は以下のような 64 ビット整数であるようです。
+--------------------+--------------------+-------------------+
timestamp (42 bit) worker-id (10 bit) sequence (12 bit) +--------------------+--------------------+-------------------+
それぞれの意味は以下の通り。細かいことは snowflake のソースコード*2を見て確かめました。
sequence: 同じミリ秒枠内での衝突を回避するためのシーケンス番号(ミリ秒ごとに 0 リセット)
worker-id: この id を発行したサーバ固有の番号 *3
timestamp: System.currentTimeMillis() - 1288834974657L の値。(2010-11-04 10:42:54 頃からの経過ミリ秒)
753177564164653056÷2^22 = 179571524659 (ms)
2.ミリ秒を日に換算
179571524659 (s) = 2078.374128 (day)
3.2010/11/4 10:42:54 の 2078.374128日後を計算する。
(エクセルだと、日付は1日が1なので、単に足し算すれば良い。)
結果は、……なんと2016/7/13 19:41になった!
ということで、ツイートのURLとタイムスタンプは一致していた。びっくりだ。
もし、ツイートのタイムスタンプを後から改ざんすることで前述のツイートを作成したとすると、タイムスタンプと同時にURLも改ざんする必要がある。
具体的なことを書く
・記録する
彼女からいつ話をされ、彼女がいつ被害にあったかを記録してくれ。日付、話した場所、内容を記録。手書きがいいが、タイムスタンプの残るデジタルでもいい。音声記録でもいい。
・彼女が飲みに行く前にやりとりしたラインなりメールなりがあるはず。それを記録にとってくれ。スクショでもいいが、画面を写真に撮った方が効力がある。
・被害にあったときの服を保存してくれ。当人が保管するのは精神的にキツイと思うので、あなたか別の場所に保管してくれ。
・早急に医者へ行き、性病検査と診断書をもらってくれ。性病検査は、あくまで相手の健康のため、というスタンスで
・弁護士無理相談がある。弁護士ドットコムから調べてくれ。だいたい電話相談ならタダだ。とりあえず電話してみるのでもいい。
・可能なら相手に会い、何をしたのか話させ録音する。可能ならだ。共通の面識があり、そういう事をしでかすクズならちょっと甘い事を言えば武勇伝みたくべらべら喋る可能性が高い。ボイスレコーダーと携帯の録音と、複数とっておくと良い。ぶち殺したくなると思うが、ぶち殺すために我慢だ。ただし負担がでかいので無理にとは言えないが…
彼女は、報復を恐れたり、そういう状況にしてしまった自分自身を責めたり、そんな事をされる自分は生きる価値が無いと思いつめているはずだ(まさにこのブコメでセカンドレイプしている奴らと同じ事を自責してしまっている)
責任をとって結婚するしないは決めなくていい、彼女と過ごした時間を思い返してくれ。彼女はそんな酷いことをされるような、されていいような人間では無いという事を伝えてくれ。
報復を恐れて訴えに出なかった人は山ほどいるが、訴えに出なかったことを後悔しなかった人間もいない。すべての人間が直ちに正しく訴えに出る体力気力を持っている訳ではない。ただいつか後悔しないために、訴えるための手段と証拠と力を取っておく手助けをしてやってくれ。
1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。
年数を下2桁だけで処理していたシステムや、2000年を平年(閏年ではない)と誤解したシステムに問題が起こる。
1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。
2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。
潜在的なバグが発覚した。シチズン電波時計やソニーのゲーム機「プレイステーション3」(閏年処理)、オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。(10ビットでは2回目)
1930年 - 2029年を下2桁で表現しているシステムに問題が起こる。同様のものに2050年問題や2070年問題などがある。
1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。
Unixなど。1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。(10ビットでは3回目)
HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。
2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
1950年 - 2049年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2070年問題などがある。
1970年 - 2069年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2050年問題などがある。
FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。
2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。
FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る(正確な日時は未定)。
2286年問題-2286年11月20日17時46分40秒に起こる。原因は、2001年問題と同じ。
Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。
知能指数の話 http://b.hatena.ne.jp/entry/www1.odn.ne.jp/drinkcat/topic/column/depot/z_tawago/z_chinou.html
ブクマのタイムスタンプは2006年8月10日。元記事は消えている。ラノベ作家さんらしい。ブクマページの転載部分から見ると2003年4月8日に書かれた記事のようだ。
リンクしてるのは例えばこの増田とか 「IQが20違うと会話が成り立たない 」 https://anond.hatelabo.jp/20090326214520
この(元)はてなダイアリーとか https://nuryouguda.hatenablog.com/entry/20071024/1193240924
2ちゃんねるでは2009年あたりが出はじめで(トラバで2003の例が示された)5年後の2014年くらいから頻繁に使われるようになったようだ。
ここ数日のバズに関して言えば震源はここかもしれない。安間 伸のAmazonダイレクトパブリッシング
安間 伸 https://toyokeizai.net/list/author/%E5%AE%89%E9%96%93+%E4%BC%B8
高知能者のコミュニケーショントラブル: IQが20違うと会話が通じない Kindle版 https://www.amazon.co.jp/dp/B07H6XG7RH
その処理に関しては、送られてきたタイムスタンプを信じて何かやるのは基本ありえないとされるけどな……
なんで時間を送らせる処理があるのか謎だが……クライアントのタイムスタンプ見る処理なんぞ書いてるパターンはほぼ無くないか。
裏でめっちゃ使われてるんだよ
https://www.google.com/search?q=oauth+%E6%99%82%E9%96%93%E3%80%80%E3%81%9A%E3%82%8C
会社でどんな影響がでるのか調べてみたので、メモしておきます。
・チャイム
40年ものの機材。始業と昼休みと終業を告げるチャイムを車内に鳴らす。放っておいても1か月に5分進む微妙な精度。サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
・FAX
時計が入っていて、タイムスタンプが入るよね。あれはあまりいじったことないけど、サマータイム機能とかなさそう。海外展開していたら、ありそうだけど、日本仕様は機能をデチューンしてそう。
UTC時を基準に動いているので、対応は可能。現在の日本ではサマータイムがないので、タイムゾーンを東京・大阪あたりを選ぶとサマータイム機能がオフになるようになっている。正式にサマータイムが決定して、windowsアップデート後にサマータイム機能が利用可能になる。
・携帯電話
いわゆるガラケー(ガラパゴス携帯)は、一応、電波で時計の調整がかかっているので、キャリアが対応すれば、勝手に変わりそうな気がする。スマホもOS自体は対応してそう。アプリは開発者ごとに国際化対応を考えていたかどうかなんだろう。
電波の元が調整したら勝手に変わるのか。テストしたことなないだろうから、実際に発動させたら大変そう。
サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
これが厄介。開始時間にバーコードを読み、さらに終了時間にバーコードを読むようなプログラムの場合、通常時間からサマータイムに変更されるタイミングにかかったときに正しい経過時間が記録されない恐れがある。多分、夜中に行うのであれば、いまのところ影響は回避できそう。24時間操業のところだと困りそう。サーバーは、そのまま放っておくというのも手のような気がした。記録を引きだす必要があるときに変換するとか、解釈するというのが現実解かも。
・予定表プログラム
同じ時間が2回くるタイミングと2時間飛ぶタイミングはどう表現しようか。深夜のことなので、寝ているだろうからスルーしていいのだろうか。切り替えタイミングのときに例外処理をいれたほうが親切かな。現時点では同じ数え方で時間が経過することを前提に描画しているので、サマータイムによる時刻の変更は想定していない。実際にない制度のことを想定してコストをかけても誰もお金を払ってくれないよね。
サマータイムの初日は、夜勤の後の朝の交代の人は2時間早くくるのか。サマータイムの終わりの日は、2時間残業しないと次の交代の人がこないのか。