「タイムゾーン」を含む日記 RSS

はてなキーワード: タイムゾーンとは

2019-10-02

ウェブマスター オフィスアワー 2019 年 10 月 02 日

ウェブマスター オフィスアワー 2019 年 10 月 02 日 メモ(※所々抜け漏れあり)

https://www.youtube.com/watch?v=bBurTQBqhS0

11/25 Webmaster Conference Tokyo:今週か来週の早い段階で情報を公開する予定

コアアップデート順位が下がった場合

金谷さんコメント

コアアップデートスパム対策としてのアップデートではなく、

最新情報への対応や常に変動するランキング対応させるためのもの

「何かまずいところがないだろうか?」という視点サイトに着手するのは不要

サイトコンテンツを見直すきっかけ程度にしてくれれば

客観的にいいのか悪いのかを知るために定期的なユーザーテスト実施とか、

お互いにレビューし合う習慣を付けるとか

品質評価ガイドラインとかE-A-Tとかは個人的には見なくても良いと思うが、

ユーザーの思う良し悪しの定義に迷った際の参考としてくれればと思う

そもそもE-A-Tが存在する領域かどうかの判断必要

順位回復については日々の細かなマイナーアップデートによって回復する可能性もある



Q.RankBrainにおける更新性や更新の有無による効果はあるのか?

A.オフィスアワーでランキング要素の可能性について言及するのは難しい。言えることはコンテンツの内容を改善してくださいということだけ。もし、更新性が影響すると言ってしまうとみんながそっちに走ってしまうので。

Q.被リンクではページランクドメインランクのどちらを重要視していますか?

A.ショートアンサーとしてはどちらでもありません。

仮にドメインランク重要ですと言ったら何が起こるでしょうか?オールドドメインの買い占めが発生してしまうでしょう。

例えばコンテンツの質を見るに、Wikipediaに関連リンクを貼られるとかそのくらいの影響力があるのかなどを見てみると良いでしょう。

ちなみに被リンク流行っているんですか?

筆者注:

【図解】グーグルリンク評価20原則2019年版】(前編#1~#10) | Moz - SEOインバウンドマーケティング実践情報 | Web担当者Forum

https://webtan.impress.co.jp/e/2019/09/30/34042

初心者必見!SEO対策の基本を5分で完全解説2019年最新版

https://emma.tools/magazine/seo-basics/

↑これら記事とか?


Q.評価や手動対策評価点を知る方法はないか

A.Googleアルゴリズム完璧ではないので、アップデートで再評価される可能性はある。

メインのクエリユーザー自身サービスが頭に浮かぶような存在になれるかどうか。

Q.robots.txtブロックしていないURLなのに、カバレッジrobots.txtブロックされていますというエラーが出る

A.色々確認中ではありますが、私が調べた範疇では問題ありません。Search Consoleフィードバックも送ってください。その際、スクリーンショットだけではなく、テキスト問題点も添えてください。

Q.サイト画像サムネイルとして表示したい。Googleが推奨する方法がありませんか?

A.特にそのやり方については公開はしておりません。Googleが良いと思った画像だけを採用します。

強いて対策を言えば、画像ヘルプを参考に画像情報Googleに伝えるようにしてください。

Q.サイトマップを送信したものカバレッジに反映されない

A.確認しましたが、Search Consoleに表示されています

タイムラグがあるかもしれませんがDisallowされていませんか?確認してみてください。

Q.HTTPSのSearch Consoleは追加した方が良い?重複コンテンツになりますか??

A.追加した方が良いです。

重複コンテンツによって、起こるのはどちらかのコンテンツ上位表示される可能性があるということ。

共倒れになるということはありません。

そのクエリで頭に浮かぶくらいの存在になっているかどうかです。

Q.セパレートURLにおいてMFI後のcanonicalURLの設定について

A.やはり動的orレスポンシブをおすすめします。

正規化とは同等のページ内容のURL複数あるからこそ行うもの

canonicalよりも、リダイレクトでやってみてはどうでしょうか?

Q.検索パフォーマンスデータ収集開始タイミングはいから??

A.基本的には登録前のデータも取れるはずですが、違うケースもあればフィードバックで教えて下さい。

Q.Search Consoleプロパティへの表示について、所有者として確認されてから日経ってもプロパティに表示されていません

A.何らかの判断時間がかかったのだと思います。通常は数日ですが、遅れたのは新規サイトであることが要因である可能性があることです。なにか不具合ありましたらSearch Consoleフィードバックをぜひお願いします。

Q.サイト個人情報を削除してほしい

A.かなり困っているご様子ですので取り上げましたが、当フォーラムでは対象外話題ですのでウェブ検索フォーラム送信願います

Q.max-image-preview robots meta の値を確認するには?

A.まだ反映されていないのでもうちょっと待てば反映されます

Q.Search ConsoleタイムゾーンについてPTからPSTPDTに切り替わりますか?

A.切り替わります!!

Q.ドメインを変えずにサイト名だけを変えると検索順位はどう変わる?

A.サイト名ほど大きな要素を変えてしまうのは影響すると思います

どういうサイト名に変えるのかも重要ユーザーにとってわかりやすくなるとかであれば、長期的には有効になるかもしれません。

Q.max-image-preview でlargeを設定するとDiscoverに表示されやすいと聞きましたがAMP対応しているだけでDiscoverに表示されやすくなりますか?

A.AMPでもmax-image-previewでlargeでもどっちでも対応可能です。

Q.自演対策に関する手動対策リクエスト

A.スパム対策担当者に送って適切な対応を行う予定です。

Q.クロールエラー特定できない件について、1月のオフィスアワーにてホスティング会社相談してみては?との回答で、のち、6月に検証中とのことでしたがあれからいかがでしょうか?

A.あまり気にされなくても良いです。ただ、間違ったエラーが表示されないようにするためにエンジニアも調整中ではあります

こういうエラーに気づかれましたらSearch Consoleフィードバックをぜひお願いします。

次回は10月後半か11月前半の予定です

2019-09-30

https://anond.hatelabo.jp/20190929180634

ドラクエ世界では勇者一行がどのように移動し続けても昼夜が変わるまでの時間は同じ。

(ルーラなどのワープ系はちょっと特殊ルールがある場合もあるけど)

まり地上全体のタイムゾーンひとつだけ。

彼らの大地は惑星ではない可能性が高く、ラナルータも自転に干渉する呪文ではないと思われる。

2019-03-01

女児ペニスを挿入したい

でも女性器が損傷するので可愛そうだからやりません。

はあ、女児普段からディルドやローターで開発するよう義務教育勉強させれば良いのに。

だって今まで性器裂傷で死んだ子供って何人いるんですか。

数え切れないですよ。その子達を救わなきゃ。

そう今日クラブ言ったんですよ、ラテン系女の子がたくさん来るクラブ

そこで仲良くなった金髪でクリっとした目の女の子に、結婚にはお金必要だっていうんです。

でも結婚して賃貸住んで子供も作らなければそんなにお金いらないでしょと言ったら、結婚には持ち家が必須条件なのが当然だしって言われその考えは無かったわ。

周りにいたペルーコロンビア人もそういうんですよ。別に彼女たち金持ちじゃないですよ。

全くどうなってるんでしょうか。そんなことに金使ってるから南アメリカは貧しいんだ。うそうそ。今後経度単位での土地面積が最も多い地域が勝つからアメリカ大陸はまだまだ有力なんですよ。

ネットワークの発展でね。それぞれの国で生まれ先天的天才割合は変わらないと研究出てたよね。そう、みんな同じ能力になったら同じタイムゾーン内でいかにチームワークを発揮できるかが鍵なんです。

からこそアフリカにみんな投資してる。アフリカはみんなすごくセックス大好きでポッシビリティの塊なのです。

いっぽうラテン系女の子は血が一瞬で沸騰するからやめとけって言われたしね。その言ってた子が今となりで寝てます

2018-10-10

anond:20181010121121

今もう「しばふ村の芋を食べさせたのは誰だ、みんなポテトになってしまった」「なんてことだ」って英語米国タイムゾーンでやってるし

日本で「アキバ系キモい」とか言ってた頃の扱いだけど、それ以外の何物でもない。例えば日本出羽守がよく想像してる"東洋反社会的宗教"みたいな扱いは無い

2018-08-16

はてなに来てるプログラマーレベルが低すぎてびっくりしてる

サマータイム関連でマウント取りたいプログラマーブコメブログ書いてるけど

まりに低レベルすぎてびっくりしてる

もしかしてこんなびっくり低レベルプログラマーが世の中のいろんなプログラミングしてるの?

サマータイムよりそっちの方が怖い。

プログラムで時刻を扱う場合ほぼほぼ100%ライブラリ機能を使う。

日付なり時刻を表すオブジェクトを作る。

そうしないと単純な引き算とか足し算が面倒だろ?

から10日後ってどうやって計算する?一ヶ月は必ず30日じゃないんだぞ?

からライブラリに任せる。そこそこのプログラマーなら面倒なことをいちいち実装しない。

で、そういう実装をすると内部で保存されてる時間情報と表示する情報は別物になる。

たいていは内部ではUTCで保存されていて、そいつを表示の時にJSTにする。

このJSTってのもハードコーディングはしない。

OSなりのロケール情報から何で表示するべきなのかを取って来てそれに合わせて表示させる。

ちなみにこの辺は意識しなくてもデフォルトでやってくれる。

サマータイム対応をする場合はこのロケール情報を変えるのであって、内部の時計は変更しない。

からほとんど全ての時間演算は影響を受けないし、コードを変える必要もない。

から正確に言うとサマータイムが導入されても「時計は変更しない」

表示を変えるだけだ。内部時計と表示の関係をわかってない人が多すぎる。

はてなの(おそらくエアプ)プログラマーがその辺をわからずに記事にしてるのがほんとキモい

で、そんじゃ影響はないか、っていうとそうじゃない。

さっきの10日後、みたいな演算は影響を受ける。2時間ずれる。

あと、簡単なところだとcronなんかのスケジューラは影響を受ける。

夜中の1時に実行するっていうcronの設定はロケールに応じて意味が変わるので、切り替えの時に1日に2回実行されたりするかもしれない。

ただ、利用者側に見えないところのスケジュール実行なら、ぶっちゃけサマータイム対応させる必要はないと思ってる。

サマータイムなんて所詮人間が見たとき時間であって、内部の時計の話ではないからだ。

エクセルタイムゾーン対応していないとかの話もあるが、スタンドアローンで動いてるなら全く問題ない。

影響は皆無ではないしかなり大きいと思うが、OS更新とかそんな大それた話ではないはずだ。(もちろん、将来的に変更する必要はある)

じゃぁサマータイム賛成なのか?って言われるとそれは別だ。

おそらくスケジューラの影響だけでも相当大変だし、それに関連したシステム再検証とかどう考えても時間が間に合わない。

内部のコードがどうなってるかわからいか時間関係してる・していないに関わらずシステムは全て再検証だろう。

どう考えても無理なのは無理だが、根本的に無理かと言われたらそうでもないはずなんだ。

ところがはてなブコメ読んでると怖くなってくる。

もしかしてハードコードJSTって書いてたり、独自時間管理ライブラリを使ったりしてる人って結構いるのか?

String time = "2018-08-16 13:41:00"

とかやってんの?

スタンドアローンならそれでもいい(勝手に電源落として時計あわせりゃいい)が、そうじゃないシステムでそんなアホなことしてる人って多いの?

そんなクソコードが溢れてるってことの方が戦慄してる。サマータイムどころの話じゃない。

2018-08-15

サマータイムB2B通信。あと費用負担の話

以前、短期間だけど、B2B通信ミドルウェアメーカーにいた。B2B通信っていうのは企業間でのデータのやりとりのこと。

あなたが近所のスーパードラッグストアで買い物をしているとする。お店は品物を仕入れるため、B2B通信で「冷えピタ20ケース売ってください」というデータを送り、受け取った卸売業者は「受注しましたよ」というデータを返す。卸売業者はさらに、メーカーに対して発注データを送り、メーカー卸売業者に受注しましたよというデータを返す。

あるいは、あなたAmazonで買い物をしたとする。Amazonクレジットカード会社請求データを送り、クレジットカード会社は成否をAmazonに返す。

あるいは、あなたが使っているA銀行の口座から、別のB銀行の口座に振込をしたとする。当然、銀行間でやり取りが行われる。

こういうデータのやり取りが、毎日恐ろしい件数で行われている。サマータイムが導入されるとしたら、B2B通信にも影響がある。ちょっと考えただけでも、

サマータイム導入が決まった場合、そういった問題が起きないように対応しなければいけないわけだけど、

限られた予算の枠内でサマータイム導入にコストを取られるということは、それ以外の施策は後回しになる。停滞のもとだ。

対応方法企業によってばらけそうなところも問題だ。B2B通信しているすべての企業が揃って完璧対応をできれば問題ない。でも、場合によっては、「うちはIT予算に余裕がないので、サマータイムの切り替わりタイミングサーバ時計を2時間ずらすだけにします」みたいなところも出てくるだろう。そうすると、「時刻は確かに2時間ずらされているけど、タイムゾーン指定JSTのまま」みたいなデータが送られてくることになる。メーカーユーザ企業の力関係にもよるけど、ミドルウェアでは「通信相手ごとにサマータイム対応方法が違う」という前提で複雑なプログラムを組まないといけなくなるかもしれない。

おそらく、サマータイムの開始・終了時には、夜間にも関わらず関係各社の担当者が待機させられることになるだろう。B2B通信も夜中には頻度が下がるのが確かだけど、ないわけではない。データの種類によっては「毎日1回夜中の3:00に送る」みたいなケースもある。万が一何も起きなければ安心して寝ればいいけど、何か障害が起きた場合、影響が大きくなる早朝までに対応しなければいけないので、ミドルウェアメーカー運用担当者も開発担当者も召集され、タクシーで集まって全員で対応するハメに、というのも十分ありうる。

海外との取引がある企業もあるから日本だけの話でもない。「へぇ日本でもサマータイム導入されるんだ。どれどれ、このJDTっていう1時間ずれるやつかな」なんて中途半端対応されてトラブルになるケースもあるかもしれない。

……ここまで書いてきて思ったけど、サマータイム対応問題なのは費用負担が一番大きいんじゃないだろうか。

オリンピックは、主催者や、そこから仕事をもらっている広告代理店建築業者、スポーツ用品メーカーなどが収入を得る。それ自体別にいいんだけど、そのためにサマータイムが導入されて、オリンピック関係ない企業や、そこで働く人たちが負担を求められている。娯楽はそもそも提供する側がサービスして、享受する側がお金を払うという交換をするわけだけど、サマータイム導入で反感を買っているのは、オリンピックから直接利益を受けない企業や人が、「あくまサマータイム対応コストがかかるのであって、オリンピックお金徴収わけではないか問題ない」という論理でタダ働きさせられることが大きい気がする。いわば、日本全体から金をふんだくって、オリンピック主催者関係者に集約するかたちになっている、その構図が問題なのではないか

そこで提案なんだけど、「サマータイムは導入してもいいから、対応にかかる費用東京オリンピック主催者請求できる」というかたちに持っていくのがいいのでは。

「いやいや、開始までの時間が残り少ないのが問題だよ」という意見もあると思うけど、費用請求できるなら、優先度上げてできることが色々増えるよね。単純に人を増やしたり、深夜残業代にあてることだけじゃなくて。

たぶん、開催時刻をずらすんじゃなくてサマータイム導入、という話が出たのも、「IOCとの契約時間が決まっちゃってるから変えると違約金払わされる」とかそういうことだと想像するので、サマータイム対応にかかる費用主催者負担して違約金回避できるなら、問題ないよね。……まさか対応費用が払えないほど莫大になることがわかっていて、それを全国の企業押し付けようとしているわけではないよね? もちろん、「サマータイム対応費用を都や国が補助金とか出して負担する」ではダメですよ。それだと結局、主催者が儲かるために国民全員に負担押し付けるかたちになっちゃうので。

いやぁ、いい案を思いついた。これなら全員がニッコリ、Win-Winな感じになれそうですね。よかったよかった。

2018-08-14

サマータイムとUTCといつもの時刻

システムの内部データは、UTCで記録しておけば、サマータイムタイムゾーンの変更という扱いで問題無く処理できる。

これは分かる。

一方で、

毎朝、日本時間午前5時に○○する。

みたいな処理は、

(A)日本時間なのだからサマータイム中も日本時間の朝5時に処理すべき。

(B)サマータイム中は1時間ずらして処理すべき。

の2つの考え方に別れてしまうので、面倒なことになる。

24時間ごとに○○するべきことであれば、(B)案が望ましい一方で、

1日の生活サイクルに密接に結び付いたもののばあいは、(A)案で行くべきだろう。

2018-08-11

サマータイムの影響を調べてみた

会社でどんな影響がでるのか調べてみたので、メモしておきます

チャイム

40年ものの機材。始業と昼休みと終業を告げるチャイムを車内に鳴らす。放っておいても1か月に5分進む微妙な精度。サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。

FAX

時計が入っていて、タイムスタンプが入るよね。あれはあまりいじったことないけど、サマータイム機能とかなさそう。海外展開していたら、ありそうだけど、日本仕様機能デチューンしてそう。

パソコン(windows10)

UTC時を基準に動いているので、対応可能現在日本ではサマータイムがないので、タイムゾーン東京大阪あたりを選ぶとサマータイム機能オフになるようになっている。正式サマータイムが決定して、windowsアップデート後にサマータイム機能が利用可能になる。

携帯電話

いわゆるガラケーガラパゴス携帯)は、一応、電波時計の調整がかかっているので、キャリア対応すれば、勝手に変わりそうな気がする。スマホOS自体対応してそう。アプリ開発者ごとに国際化対応を考えていたかどうかなんだろう。

会社玄関にある電波時計

電波の元が調整したら勝手に変わるのか。テストしたことなないだろうから、実際に発動させたら大変そう。

各部屋にあるかけ時計

サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。

webサーバー上で現在時刻を取得するプログラム

これが厄介。開始時間バーコードを読み、さらに終了時間バーコードを読むようなプログラム場合、通常時間からサマータイムに変更されるタイミングにかかったときに正しい経過時間が記録されない恐れがある。多分、夜中に行うのであれば、いまのところ影響は回避できそう。24時間操業のところだと困りそう。サーバーは、そのまま放っておくというのも手のような気がした。記録を引きだす必要があるときに変換するとか、解釈するというのが現実解かも。

・予定表プログラム

同じ時間が2回くるタイミングと2時間飛ぶタイミングはどう表現しようか。深夜のことなので、寝ているだろうからスルーしていいのだろうか。切り替えタイミングとき例外処理をいれたほうが親切かな。現時点では同じ数え方で時間が経過することを前提に描画しているので、サマータイムによる時刻の変更は想定していない。実際にない制度のことを想定してコストをかけても誰もお金を払ってくれないよね。

24時間交代勤務シフト

サマータイム初日は、夜勤の後の朝の交代の人は2時間早くくるのか。サマータイムの終わりの日は、2時間残業しないと次の交代の人がこないのか。

サマータイムしない会社

サマータイムしませんという会社が現れたら、どうなるんだろう。取引上こまることはあるかな

また、思いついたら書きますではではー。

東京オリンピックマラソン開始時刻って

欧米テレビ放映の都合で朝7時開始になったんでしょ?

だったら、サマータイム導入して「ほら7時開始のままで暑さが和らいだでしょ?」ってやったって、欧米タイムゾーン基準ではけっきょく開始時刻がずれちゃうんだからダメなんじゃないの?

妄想サマータイム対応してみようとしてみる

サマータイムタイムゾーン一種と考えることもできるので(該当時期だけタイムゾーンがずれると解釈できる)、複数タイムゾーンにすでに対応しているシステムだと導入は楽だ。

アメリカ場合タイムゾーン西部中部東部と3つあるので国内向けのシステムでもほとんどがタイムゾーン意識して作られているし、そもそもタイムゾーンが導入されてから長い。

ところが、日本はどうだろうか?

日本結構東西に長いのだが、タイムゾーンは一つしかない。日本標準時 JST だ。 UTC より9時間すすんでいるので (UTC+9)と表記される。

複数タイムゾーン対応したプログラムを作る場合は、内部では UTC に変換して処理や保存を行い、表示と入力部分だけ現地時間対応するのが一般的だ。

サマータイムになろうが、別タイムゾーン飛行機で移動中であろうがUTCは常に進み続ける。(正確にはうるう秒があるので1秒間足踏みしたりするのだが)

ローカルタイムサマータイムになった日とか場所を移動した日には前後に飛んでしまうので時刻順にデータ並べ替えたりするのには使えないのだ。

ちなみにアメリカ軍の戦闘機F-22日付変更線を超えて沖縄に初めて来たときソフトウェアバグって修理のためにアメリカに帰って行ったことがあった。笑いごとではない。

さて、日本中にある既存システムはどうだろうか?君の作ったシステム、関わったシステムはどうだろう?

MySQLシステムタイムゾーンJSTにしていたりしないか

JSTで保存して、JSTで出力すればタイムゾーンの変換なんかしなくていいじゃん?だって日本しか使わないんだぜ?言語バリアがあるからね(はぁと」

なんてシステムはざらだ。下手すら時刻を文字列型としてJST前提で保存してたりして。

他のシステム相互通信するソフトウェアはどうだろうか?相手タイムゾーンJSTである仮定していないかアメリカ西海岸から接続があった時も大丈夫か?

てか、そもそもロジックと表示部分がちゃんと分離されているかモデルとビューの分離。教科書でならっただろ?

おいおい、ビューで計算したものモデル側で未チェックで保存したりしてないよな?

テストは書いてあるか?タイムゾーンが変わって時間が飛んだり戻ったりしたデータが送られてきてもこけないようになっているか

そもそもテストは書いたことあるのか?てかソースそもそもあるのか?

あー・・頭痛くなってきた。やめよう。

大臣、無理です!」

2018-08-10

そもそも時刻を設定できる機器は時刻を修正できるようになっているだろうし

自動的に時刻を修正する機器は、一括で修正できるだろうし

それによって不具合が起こるとしたらそれってそもそもバグじゃないの?

ていうか時刻は修正しなくてよくない?表示方法を変えるだけじゃないの?

タイムゾーンを変えるだけでいいはずだけど何が問題なのかさっぱり分からん

2018-08-09

サマータイムの何が問題なの?

システム面で問題とか言ってる人は本当にシステム開発したことあんの?

一番びびったのは

スマホサマータイム対応させるにはOS更新必要!」

とか言ってる人.

普通にスマホの設定からタイムゾーンを+9から+11に変更したら変更できるんですけど.

そもそもタイムゾーンネットワークから設定できるので通信会社が変更すれば変わりますけど.

海外旅行行ったことないの?勝手に変わるでしょ?知らないの?

まぁそりゃぁ一部のアプリタイムゾーンをいきなり変えたら不具合起きるかもしれんけど

はっきり言って今のご時世でタイムゾーンを考えないでアプリに時刻の概念を導入している時点でお察しですよ

システム系は大変なんだ!」

みたいなこと言ってる人いるけどさ,具体的に何が大変なの?

OSタイムゾーン+11にするだけでしょ?そりゃテストかいるけどさ.

それで不具合が出るようなプログラムって逆にどうやって作るの?

時刻とかライブラリ越しで取得するでしょ?そいつUNIX時間に変換して計算するなりDBに入れるだけじゃないの?

表示の時もシステムタイムゾーンで表示するでしょ?ハードコードで+9とかJSTって入れてるってこと?

そんなプログラムはどっかに致命的なバグ抱えてるからこれを機に入れ替えた方がいいよ.マジで

一心なのはスケジューラ系だけど,逆にそこさえチェックすればどうにでもなるんじゃないの?

もちろん不具合を起こさな機器が皆無とは言わないけど

たかだかサマータイムっていうかタイムゾーン変更に対応できないような機器が基幹系に入ってるとかぶっちゃけ入れた奴が悪いし

どうでもいい機器の内部時計がズレててもどうでもよくね?

てかそういうのは手動で合わせればよくね?合わせられない機器ってあるの?

「小さいIoT系の機器は手動で合わせるの大変」

って,そもそもIoT系の機器は盛大にズレるのでntp必須ですけど.使ったこと無いの?

サマータイムっていう制度問題があるってのは理解できるので導入には全然賛成じゃないんだけど

別に入れてくれって言われたら来年の夏とか余裕で対応できると思うから全然楽観的なんだけど.

2018-08-08

サマータイムがなぜダメ

書いたのは私じゃないけど本人が拡散希望してたので掲載

昨日、菅官房長官夏時間検討否定していて一安心していたのですが、まだ前向きなのではないかと思われる報道がありましたので、もう一回しつこくポストします。

安倍首相サマータイム検討を指示 自民党部会

https://www.fnn.jp/posts/00398120CX

IT業界の皆さん、自分意見議員官邸に伝えましょう】

夏時間を推進しようとしている議員ネット情報収集する人種ではないことは、SNS上での皮肉批判にもかかわらず、こうして事態が進行していることからあきらかです。FAXとかはがきじゃないとだめなのかもしれませんが、幸いWeb上にフォームがあるので、自民党首相官邸に今すぐ自分意見を伝えましょう。

首相官邸への意見

https://www.kantei.go.jp/jp/forms/goiken_ssl.html

自民党への意見

https://www.jimin.jp/voice/

なぜ、限定的問題解決するために社会全体の構造を変更しようとするのでしょうか。私はこのような全体主義的な問題解決姿勢には大反対です。仮に開催を2時間前倒すことで猛暑オリンピック実施することに伴う様々な問題解決するとしても、変更が必要なのはオリンピックタイムテーブルであり、社会全体の時刻ではありません。

IT業界でない方向け:突然のサマータイム導入のヤバさ】

ざっくり言うと、私見では2000年問題と同じぐらいヤバく、準備期間が少ないという意味破滅的にヤバいです(=回避不能2000年問題)。

世界中夏時間と冬時間に2時間の差がある国はありません(間違っていたらご指摘ください)。ベストプラクティス存在しません。

・何を大げさな、単に時計を進めたり戻したりすればいいだけじゃないか、と思うかもしれませんが、現代コンピューター世界中の様々なサービス通信しています。そのため、時間を扱う際には内部的には一旦世界標準時で処理されるのが一般的で、内部時計を二時間進めたり戻したりすると様々な問題が起こりますロシア/マガダン時間はすでに東京よりも二時間進んでいるので、現実的にはユーザースマホPCの時刻自動設定を解除し、手動でマガダン時間に変更するしかないと思います

海外からオリンピックを観に来る旅行者にも「スマホ自動タイムゾーン設定を解除してロシア/マガダン時間に設定してください、マガダンスペルはM, a, g, a, d...」などと航空会社が案内する感じになるでしょう。日本に来るのになぜかロシア時間

・一方で、20世紀から稼働している古いシステムや、単純なシステムの中には、そもそも単一タイムゾーン以外で動作することを考慮していないプログラムもあり、このようなシステムについては、内部時計をずらして対応するしかありません。このようなシステムから見ると、突然タイムスリップした状況に見えます。進む方はまだいいのですが、戻る方の処理は大変複雑です(たとえば、切替日の深夜営業飲食店では、すでにタイムカード23:30で打刻した人のあとに、22:30の打刻が出現するような状況になる)。この影響範囲についてはまったく予想がつきません。いい加減に対応すると、時計を進めていないサービス現在時刻で同意できないために、通信ができないような事態が起こります

夏時間概念自体は新しいものではないので、ちゃん日本夏時間標準化され、各種OS対応することが前提であれば、工数をかけて設計実装を行えば、最新のOS上で新しく開発されるシステム理屈上は問題なく対応することができます

しかし、日本だけでなく世界中ですでに稼働している、時刻を表示する無数のプログラムについては、時刻表示必要な処理や時刻設定に必要選択肢を書き足す必要があります日本政府が公式ロシア/マガダン時間採用すると宣言しない限りは)。十分な準備期間を取らずに、変更が必要な箇所をすべて洗い出し、問題なく修正するのは大変むずかしいことです。また、上述のように、古いシステムではそもそも変更が不可能なこともあります

万が一いいかげんな実装適当設計が行われるシステムが混じっていると、そのシステム通信する際に2時間時間がずれて処理が行われるようなことが起こります。具体的には様々な表示時刻や予約時刻が2時間ずれたり、通信不通になるなどの問題が起こり得ます

この結果、

日本夏時間正式対応したシステム(最新の国産スマホ

日本夏時間正式対応していないので、ユーザーが時刻をロシアマガダン時間に手動設定することで当面正常動作するシステム(古いスマホPCなど)

日本夏時間にいい加減に対応して問題を起こすシステム

日本夏時間対応しないために、内部時計を進めたり戻したりして対応するシステム

日本夏時間対応せずに日本標準時間のまま動作し、ユーザーが時刻を頭の中で変換しなければいけないシステム

が混在することになり、社会的な混乱は必至です。

人間機械も「それ、どっちの13時?」みたいに迷い、間違えるという毎日がやってきます文房具屋のレシートには日本標準時が、コンビニレシートには日本夏時間が印字されているような感じになるでしょう。ツイッターフェイスブックなどのもともと複数タイムゾーン対応しているシステムや、JR航空会社など大きい会社はたぶんちゃん対応してくれますが、美容院の予約システムや小規模なネット予約システム対応できずに日本標準時のまま稼働し続け、勘違いが起こります

社会的に大きなメリットがあるのであれば、この大混乱のリスクを取ってでも前進するべきだと思いますが、本件については導入のメリットがあまり限定的であり、得られるメリットに比べてリスクが大きすぎると思います

とにかく2020年サマータイムはやめてください。死人が出ます。お願いします。

2018-08-07

anond:20180807154059

普通にあるよ

最初から改元とかタイムゾーン対応もできたけど

納期お金問題でできなかったのに

「あれ、対応してないの?追加料金は払わないよ」とか普通にある

半分はクソ営業のせい

2018-06-12

anond:20180612032827

多くのWebサービス広告収入で稼働している。増田もそうだ。

実験としての増田面白さは運営業態にある。

アフィリエイト収入により運営するのではなく、広告投稿ツール販売することで運営しているのだ。これにより広告代理店を介さずにベンダー簡単広告うつことができる利点がある。

そしてインターネットにおけるタイムゾーンによる棲み分け画期的といえる。煩わしい広告も、真夜中に投稿すれば日本ユーザーには気にならない。だからうち放題にできる。

ブラジル日本語できる人がもう少し多かったら面白いことになってたと思うね。

その点チャイナなんかはいいかもしれない。華僑世界中いるから。

2017-11-18

遠距離恋愛秘訣

日本ヨーロッパといった超遠距離恋愛秘訣をこれまでの経験をふまえて。

日本国内での遠距離恋愛では、時差もない、会おうと思えばお金さえ払えば数時間で会える。わけですが、日本ヨーロッパともなると、会おうと思い立ってから実際に会えるまで24時間くらいはかかってしまうし、お金だって少なくとも往復で10万はかかります。安くしようと思うと会うまでに要する時間もっと増えます。乗り継ぎの乗り継ぎを重ね、遠回りすることになるので。ドバイとか経由すると安いですが、距離が2倍近くなりますよ。

話が逸れました。

まず、なにより大切なのは相手を信頼すること。そんなに難しいことではないです。けど、それが一番難しいのも事実で。

ではどうやって信頼するか。

定期的に連絡をとる。これはやっぱり必要です。連絡の頻度は2人のタイプによります日本にいても結構会いたいタイプの2人なら、毎日連絡したって構いません。

毎日電話しても構いません。お互いのことを信頼できるのなら、いくらでも連絡すれば良いのです。

落ち着いてきたから連絡の頻度を下げようか?そんなことを考えることもあるでしょう。しかし、無理に頻度を落とす必要はありません。2人が連絡をとりたいのなら連絡すれば良いと思います。ただし、相手負担にならないことは重要です。

特に日本ヨーロッパでは時差がかなりありますサマータイムが終わると時差がさらに1時間大きくなるので、連絡する時間帯を変えた方が良いことも。

お互いに働いているのなら、ヨーロッパが夜で日本が朝というのが連絡しやすいかも。ただし、日付が違うので「今日」とか「明日」という言葉意味をなしません。

相手タイムゾーンを考えながら、思いやりをもって話しましょう。また、深夜のテンションと早朝のテンションという落差が発生する可能性があります。この点も相手のことを考えてあげられると理想的です。夜の側は下ネタとか言い出すこともあるので、広い心で受け入れてあげましょう(笑)

お互いに学生だったり、時間の融通が利く職業なのであれば、そこは柔軟に対応するのもありです。お互いの負担にならない時間帯を選びましょう。

こんな感じで、電話はやろうと思えば毎日でもできます毎日電話をしていても、定期的に行って欲しいことはテレビ電話です。

顔を見るのは恥ずかしい?気持ちはわかりますが、やっぱり顔を見ながら話すのって大事ですよ。電話では見落としている部分もあります恋人ほど他人と近い関係になることって普通はないので、お互いのことをよく知るためにも、思いやるためにもときどき顔を見て話すのが良いと思います。2人の休みが合うときにはぜひテレビ電話を。

電話はこんな感じで。LINEとかメッセージはどうしようか。それは毎日したほうが良いかなー。おはよう。おやすみ。だけでも良いと思います。もちろん、もっと送りたければどうぞ。「今日は天気がよくて気持ちいいよ」とか、些細なこともシェアするのは良いことです。物理的な距離が離れているので、心の距離を近くするには良さそう。電話毎日しなくても、ちょっとだけメッセージの交換を毎日しているのは良いと思います自然消滅防止のためにも大事ではないかと思います

日常の連絡はこんなものかな。

たまには手紙を書いてみたり、贈り物をするのも良いと思います男性から女性にこれをやるときっと喜んでくれますよ。特に手紙は超遠距離でもないと書く機会がないと思います。将来結婚でもしたら良い思い出になると思いますので、オススメです。

どんなにマメに連絡していても、やはり「会う」ことは重要です。常に次のデートの予定を持っておくのはとても重要なことだと思います

それが数ヶ月先だとしても、2人にとって楽しみなことが待っていると辛くても頑張れます

仕事日本に帰る用事があるなら、そのときに少しでも会う、デートする。というのが良いと思います。2人の休みが会えば、ヨーロッパを一緒に旅行するのも良いでしょう。もちろん、中間地点で会うのも良いかもしれませんが、毎回中間地点で会うのは、「会う」という目的を達成するためにはあまり経済的ではありません。もちろん、2人が旅行したい場所中間地点にあるのならば良いと思います

経済的に考えるなら、どちらかがもう一方のところへ会いに行く。というのが良さそうです。相手の家に泊まれ宿泊費もかかりませんし。ただし、いつも同じ方が会いに行くというのは経済的負担の偏りが2人の関係悪化させてしまうこともあるので、滞在中の食事代はもう一方が出すとか、何か対策を講じましょう。いずれにしても、うまくバランスを取りながら定期的に会う予定を入れておくことは必要です。重要です。定期的に会うことで、信頼も深まります

まとまりがありませんが、経験に基づく超遠距離恋愛秘訣でした。これから遠距離恋愛の予定がある方、うまくいくことを祈っています

2016-10-09

vim pluginの先頭に書いてあるLast Changeって

タイムゾーンは何を基準にしてるの?

2016-03-10

http://anond.hatelabo.jp/20160310212632

よく分からん20:40(8:40AM?)に書かれて消えたエントリでもあんの?

俺いま時差あるしなあ。増田の表示のタイムゾーン日本で固定っぽいが。

2015-02-24

anond:20150223235308

ユーザーID+パスワードハッシュ化しとけば

これだと、後日ユーザーIDを変更できなくなるね。

ユーザIDは変更させない仕様にするからいい? 顧客に対しては確かにそれでいいかもしれない。でもfuckとかsuckとかrootとかadminとか、あなたの社名とか、あるいは後日の事情でその文字列塩梅が悪くなったら、どうする?

GUID+パスワードで、そのときのGUIDを一緒に保存とか。

GUIDが何を指すかによるけど、これはアリ

初回登録日時でも悪くなさそう。

十分に悪くないけど、日時って精度やタイムゾーンや暦というファクターがあるものから、少し気持ち悪い。

time_t的なものなら大丈夫? そうだね。でも「初回登録日時」が何を指すか、パスワードを決めさせる前の仮登録なのか本登録なのか、解釈が揺れるリスクが少しありそうなのも気持ち悪い。

これらはどっちかというとコード保守範疇の話だけどね。でもいつかの未来にタコなスタッフが不十分な理解コードをいじる可能性を考えると、やっぱり気持ち悪い。

最悪アプリ固定のキーワードとか。

これもアリ。いわゆるsaltだね。というか、これ「も」使うのが普通

まり、guidsaltパスワード文字列をくっつけて、不可逆に変換するのが定石どおりでいいんじゃね?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん