テクノロジー
『ソフトウェア設計のトレードオフと誤り』を読んで、”日付や時刻”を扱うことの難しさについて考えた - Magnolia Tech

気に入った記事をブックマーク

気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
記事を読んだ感想やメモを書き残せます
非公開でブックマークすることもできます

『ソフトウェア設計のトレードオフと誤り』を読んで、”日付や時刻”を扱うことの難しさについて考えた - Magnolia Tech

テクノロジーカテゴリーの変更を依頼記事元:

blog.magnolia.tech

適切な情報に変更

エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます

コメントを非表示にできますコメント表示の設定

ブックマークしました

ここにツイート内容が記載されますhttps://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

次回からTwitterへ自動リダイレクト

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

494usersがブックマークコメント

コメントするにはログインが必要ですブックマークを追加

ブックマークを追加

よく使うタグ

『ソフトウェア設計のトレードオフと誤り』を読んで、”日付や時刻”を扱うことの難しさについて考えた - Magnolia Tech

494 users

blog.magnolia.tech

よく使うタグ

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント36件

注目コメント
新着コメント

nemoba「期間の末尾が祝日の場合に満了は翌日になる。」という民法があるかぎり、みんなまともにサービス作れてないからおｋ。

2023/07/18リンク

その他

prograti民法が定める期間の計算http://www5d.biglobe.ne.jp/Jusl/TomoLaw/KikanLaw.html

2023/07/18リンク

その他

Eiichiro”顧客は3ヶ月以内は返品可能”と書かれた条件を実装する上で、どれだけ色々な条件を整理し、要求を出した人と合意しないといけないのか“想像しただけで、あ゛〜。ってなる。

2023/07/17リンク

その他

sds-page締め日が云々言い出すと死ぬ。月次繰り越ししちゃったけどキャンセルさせてとか言われて二度死ぬ

2023/07/18リンク

その他

y_as“要求を出した人と合意” 「え！お得意様なら多少の期間オーバーでも返品可能だから、顧客マスタに「お得意様ランク」、お得意様ランクマスタに「返品猶予日数」を持たせるんですか！？」

2023/07/18リンク

その他

emt0システムに合わせた業務じゃなくて業務に合わせたシステムを作ろうとするとこうなる。あと開発に現場入れないとか情シスが業務知らないとか面倒になって今と同じとか言うとか。いっそシステム入れない方が幸せ。

2023/07/18リンク

その他

nharuki原理主義者なので時刻データは「保持は(可能ならミリ秒以下単位の)Unix時刻」「表示はISO8601形式」で統一しろ！っていっつも思ってる。なおタイムゾーン＆サマータイムは(文字数

2023/07/18リンク

その他

NOV1975まだパラパラしか見てないけど、いろんなトピックが「ああこれ言う原理主義者いるなあ」に対抗できそうな話満載でとても良いですｗ

2023/07/18リンク

その他

laranjeiras紀元前を扱うときに苦労した。西暦1年の1年前がゼロ年じゃなくて紀元前1年になるのが大変で、内部的には紀元前10万年をゼロとしたカレンダーで統一し、AD、BCは元号のような表示上の処理で済ませた。https://nenpyou-mania.com/

2023/07/18リンク

その他

irh_nishiタイムゾーンの話とか表記の話とかUnixtimeにしたときの確認のしづらさとかJavaScriptはミリ秒だったりするとかそういう話が書いてるのかと思ったら要件定義の話か。タイムゾーンは暗黙的にJSTにする人多いよね。

2023/07/18リンク

その他

natsutan“そして更に大事なのが「7.2 日時情報を仕事で扱うための準備」という章で、もうこの章だけでも4180円を払う価値が有る、有りすぎる。”

2023/09/11リンク

その他

watuki気になってた本について～。後で読む。本読みたい

2023/07/19リンク

その他

suika3417この本注買うの忘れてたの思い出した

2023/07/18リンク

その他

Hamachiya2ラジオやテレビ局絡みの案件だと何日の28時みたいな概念も出てくるよ

2023/07/18リンク

その他

paradisemaker定期的にサマータイムで炎上する理由

2023/07/18リンク

その他

daishi_n時間は暦の問題、タイムゾーンの問題、当時の日時と魔窟だからね。あと基準となる日時などの履歴をどう持つかとかも

2023/07/18リンク

その他

gabari4/5/2023が4月5日か5月4日かとかいう話もあるからな…（読んでないけど入ってそう）/C#も、DatrTime型とDateTimeOffset型があり先人の苦悩を垣間見ることができる

2023/07/18リンク

その他

rryu「期間が1日0時から始まらない場合、どこからどこまでが3ヶ月なのか」だけでもう色々めんどくさい。

システム開発

2023/07/18リンク

その他

ka-ka_xyz日付時刻辺り（複数タイムゾーンを跨ぐ締め切りをめぐるあれこれ）は以前の会社で結構苦労してたとこでもあるので買おう（「内部的にunixエポックならどうとでもなるんじゃね？」というのは往々にして泥沼への第一歩

2023/07/18リンク

その他

tasukuchan最近は、UNIX time(整数か浮動小数かは要件によって変える)で取り回し、nowは関数の引数に入れる、という感じ

2023/07/18リンク

その他

uchiten前に買おうとして高くてやめたんだけどやっぱり買おうかな……。

2023/07/18リンク

その他

2023/07/18リンク

その他

NOV1975まだパラパラしか見てないけど、いろんなトピックが「ああこれ言う原理主義者いるなあ」に対抗できそうな話満載でとても良いですｗ

2023/07/18リンク

その他

khtokageブコメでも経験のあるなしでの温度差が凄い笑

2023/07/18リンク

その他

2023/07/18リンク

その他

regularexception祝日マスターや祝日API作ったり叩くのやだー

2023/07/18リンク

その他

minamishinji本買ってるけど読んでない。夏休み、ほんとに読もうかな。

2023/07/18リンク

その他

da-yoshiJavaのDateTime系は複雑だけどこれのおかげで日付関連でやるべきことを学べた

2023/07/18リンク

その他

2023/07/18リンク

その他

dekokunいいな。

2023/07/18リンク

その他

Sampo”顧客は3ヶ月以内は返品可能”、ええ、聞いただけで頭に激痛が⋯　詳細仕様パッケージを逆に押しつけるくらいには図太くなりましたが。「UTC+9で決済完了瞬間の日付の3ヶ月後の同日（なければ翌月1日）24時直前まで」

2023/07/18リンク

その他

nemoba「期間の末尾が祝日の場合に満了は翌日になる。」という民法があるかぎり、みんなまともにサービス作れてないからおｋ。

2023/07/18リンク

その他

2023/07/18リンク

その他

versatile月末に実行され月をまたぐと集計できなくなるバッチ作ったやつちょっとこい！！

2023/07/18リンク

その他

getcha返品のシステム実装した事ないけど、要件を聞いただけで、きなくさい匂いをぷんぷん感じて楽しそう。想像力が試されるやつ。

2023/07/18リンク

その他

prograti民法が定める期間の計算http://www5d.biglobe.ne.jp/Jusl/TomoLaw/KikanLaw.html

2023/07/18リンク

その他

hirosheへーと思ってこういう本買って読んでも大概よく分からない。翻訳された文章ってどうしてもスッと頭に入ってこなくて、オライリー本をスッと読める人たちってどういう読み方してるんだろ。

2023/07/18リンク

その他

sds-page締め日が云々言い出すと死ぬ。月次繰り越ししちゃったけどキャンセルさせてとか言われて二度死ぬ

2023/07/18リンク

その他

2023/07/18リンク

その他

hiroomi”「7.2 日時情報を仕事で扱うための準備」という章で、もうこの章だけでも4180円を払う価値が有る、有りすぎる。”

2023/07/18リンク

その他

コメントするにはログインが必要ですログインしてコメント

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

usersに達しました！

さんが1番目にブックマークした記事「『ソフトウェア設...」が注目されています。

気持ちをシェアしよう

ツイートする

『ソフトウェア設計のトレードオフと誤り』を読んで、”日付や時刻”を扱うことの難しさについて考えた - Magnolia Tech

ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには作者:Tomasz Lele...ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには作者:Tomasz Lelek,Jon SkeetオライリージャパンAmazon ソフトウェア開発経験の最初の段階で「一つの機能には複数の選択肢が有って、メリット・デメリットがそれぞれ有り、それらはトレードオフの関係に有り、容易には決めることができない」という事実を教えてもらえる機会に遭遇できていれば、その人はとても幸運だと思う。先輩や上司が一方的に、「一つの確かな方法」をただ伝える、みたいな場面（それが必ずしも一般的にはそうとは言えない方法であったとしても）も多いのではないでしょうか。どんなに設計上の意思決定ができている人でも、その頭の中では「色々な選択肢の中で悩んで、ベストではないかもしれないけど、前の前の課題に対してよりベターな方法」を選んでいる。でもその思考の過程を見せてくれる人はとても少ない。