Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

PostgresのAT TIME ZONEが「UTC変換」だと思われがちな落とし穴

Postgresで日時を扱うとき、AT TIME ZONE 'UTC' は便利そうに見えます。ですが、実際には「UTCに直す」という単純な処理ではなく、型そのものを変えてしまうので、思い込みのまま使うと結果がずれます。元記事はこの勘違いがどこで起きるのかを丁寧に示し、さらに一度だけで済ませず、場合によっては同じ指定を二回繰り返す必要がある理由まで触れています。日時バグは後から見つけにくく、しかも小さな違いが請求、集計、検索条件にそのまま効くので、かなり実務的な話です。

AT TIME ZONE 'UTC' は「変換」ではなく型の付け替えに近い

元記事の出発点は、AT TIME ZONE 'UTC' という書き方が多くの人の想像と違う動きをする、という指摘です。Postgres では timestamptz と timestamp が別物で、前者はタイムゾーン込みの時刻、後者はタイムゾーンを持たないただの日時です。ところが AT TIME ZONE 'UTC' を timestamptz に使うと、単に「UTCにした文字列が返る」のではなく、timestamptz から timestamp に型が変わります。元記事はここを最重要ポイントとして挙げています。

しかも、その結果として手元に残るのは、タイムゾーン情報を失った timestamp です。見た目はそれらしくても、内部では「その時刻がどのタイムゾーン基準なのか」が消えています。元記事は、timestamp without time zone はかなり避けられるべき型だと強く言っています。理由は単純で、後から別のタイムゾーンと比較したり、DBの設定が変わったりしたときに、意味があいまいになるからです。

さらに厄介なのは、timestamp と timestamptz の等価比較です。元記事によると、この比較は基本的に常に false になります。例外は、Postgres のデフォルトタイムゾーンが UTC の場合だけです。つまり、開発環境ではたまたま動いて見えても、本番でズレる余地がある、ということです。元記事はここを「落とし穴」として扱っていて、AT TIME ZONE 'UTC' を一度書いただけでは、期待した意味にならない場面があると説明しています。要するに、UTCにしたつもりで、実際には「UTCという名札を外した日時」が残ってしまうわけです。

型を壊さずに済むはずの場所で、なぜこんな罠が残るのか

この話で気になるのは、なぜこんなに素直でない仕様が今も残っているのか、という点です。私は、Postgres の日時型は「便利な抽象化」と「厳密な表現」の折り合いが最も難しい領域の一つだと思います。人間は「この時刻を UTC に直したい」と考えますが、DB は「どの型の値を、どの型に落とすのか」をまず処理します。そこが一致していないので、見た目の直感が外れるのです。

しかも、日時のバグはエラーにならず、値が静かにずれるのが厄介です。検索条件なら、あるレコードだけ抜ける。集計なら、日付の境目で数字が変わる。請求やログの監査なら、あとから説明しづらい不一致が残る。元記事が timestamp を強く警戒しているのは大げさではなく、こうした「壊れ方」が最も面倒だからでしょう。DBは間違いを派手に止めてくれるとは限らず、むしろ間違ったまま通すことがあります。

私が特に重要だと思うのは、AT TIME ZONE 'UTC' を「文字列の正規化」と誤解しやすい点です。実務では「保存前に UTC にそろえる」「表示時にローカルへ戻す」という発想がよくありますが、Postgres ではその途中で型の意味まで変わることがある。ここを曖昧にしたまま ORMs や SQL 断片を積み上げると、どこかで二重変換や未変換が起きます。時間が経つほど原因追跡が難しくなるので、日時処理は最初の設計でかなり勝負が決まる、という話だと受け取りました。

「UTCにしたい」は十分な仕様ではない

元記事を読んでいて、改めて感じたのは「UTCで保存したい」という要求が、技術的にはまだ雑だということです。欲しいのは UTC そのものではなく、「あとで見ても解釈がぶれない表現」です。そこを曖昧にしたまま AT TIME ZONE 'UTC' を使うと、DB は親切に見えて実は別の型を返し、こちらの期待は簡単に外れます。

実務でよくあるのは、アプリ層では ISO 8601 の文字列、DB では timestamp、API では timestamptz といった具合に、層ごとに日時の持ち方が混在するケースです。そうなると、どの段階で何回変換したかを人が追いにくい。元記事が「二回繰り返す必要があるかもしれない」と示しているのは、まさにその危うさの表れだと思います。変換回数が増えるほど、意図と実装のズレは起きやすくなります。

それでもこの手の問題がなくならないのは、日時が「人間にとって自然」な一方で、「計算機にとっては例外だらけ」だからでしょう。夏時間、地域差、DB のデフォルト設定、比較演算の暗黙変換。どれか一つでも変わると結果が変わります。だから私は、日時処理は「正しい SQL を一行書く」より、「曖昧さをどこで潰すかを決める」仕事だと思います。元記事はそのことを、かなり実務寄りの警告として書いていると感じました。

開発者が覚えておきたいのは、見た目より型を見ること

この種の話で一番大事なのは、結果の見た目ではなく、返ってくる型を確認する癖だと思います。AT TIME ZONE 'UTC' を使ったあとに何が残るのか、そこを意識しないと、コードレビューでもテストでも見落としやすいからです。日時は表示上は正しく見えることが多く、しかも本番に行ってから問題化しやすい。だから「見えている値」より「どう保存され、どう比較されるか」を優先して考えるべきです。

元記事の価値は、単なる小技紹介ではなく、「UTCにしているつもり」の危険を言語化している点にあります。SQL は短く書けるぶん、何が起きているかを省きがちです。そこに timestamp と timestamptz の差が入ると、コードは動いても意味がずれる。私は、この手の警告は PostgreSQL ユーザーだけでなく、日時を扱うすべてのバックエンド開発者に通じると思います。

参考: Postgres AT TIME ZONE 'UTC' does NOT do what you think it does

同じ著者の記事

PlanetScaleがPostgres向け全文検索「TIN」を出した理由

PlanetScaleが、Postgres向けの全文検索拡張「TIN」をGAとして公開した。検索エンジンというと専用プロダクトを思い浮かべがちだが、今回の話は「Postgresの中でどこまで実用的な全文検索をやれるのか」に踏み込んでいる。しかも単なる追加機能ではなく、更新が続く本番DBで検索を走らせる前提にかなり強く寄せているのが面白い。この記事では、その主張とベンチマークの見せ方がかなりはっきりしている。 PlanetScaleは、顧客から最もよく求められるPostgres機能のひとつが全文検索だとして、TINを発表した。TINは “Text INdex” の略で、PostgresとNekiの両方で使える全文検索拡張としてGA扱いになっている。使い方は素直で、`CREATE INDEX ... USING tin(...)` でインデックスを作り、`==>` 演算子で検索する。元記事では、商品説明から「stretch denim jeans」を含む上位10件を返す例、メール本文から特定の語を含む文書を拾う例、写真のタグの件数を数える例が示されていた。 PlanetScaleがTINに

papoo.work

小さな技を集める人は、仕事を少しずつ速くする

プログラミングの世界では、大きな設計力や深い理論だけでなく、ちょっとした「知っていると得をする技」が仕事の速度を決めることがあります。今回の文章は、その小さな知識の価値をあらためて見直した短いエッセイです。派手な新技術の話ではなく、ターミナル、SQL、git、正規表現、Node.js といった日常の道具をどう使いこなすかに焦点を当てています。読み終えると、経験の差はコード量だけでなく、こういう断片的な知識の蓄積にも表れるのだと分かります。 著者の主張はかなり明快です。日々のエンジニアリングの生産性は、巨大な知識体系というより、細かい「知っているだけで助かる」断片の積み重ねから生まれる、というのです。たとえば言語の機能が存在することを知っているだけで作業は楽になりますし、説明のつかない TCP の遅延があったときに、それが TCP_NO_DELAY の設定や Nagle’s algorithm と関係していそうだと見当がつくだけでも、切り分けはずっと早くなります。git で詰まったときに抜け出すための定番コマンドや、sed でファイルを書き換える小技も同じ扱いです。 そのうえで著者は、特

papoo.work

4BモデルにPostgres超えのクエリプランを学習させた話

Postgres のクエリオプティマイザは本当に賢いのか。Rohan Bansal の記事は、その問いに対して小さな open-weights モデルを使ってかなり挑んだ実験を紹介している。題材は SQL の join order と実行計画で、しかも単なるベンチマーク比較ではなく、reinforcement learning まで使ってモデルを後から鍛えたという点が面白い。データベースの内部で何が起きているのかが分かるだけでなく、LLM を「文章生成」以外にどう使うかの実例にもなっている。 記事の中心は、4Bサイズの Qwen モデルを後学習させて、Postgres のデフォルトより速い query plan を出させた、という実験だ。筆者はまず、クエリオプティマイザが何をしているのかを、IMDb データセットの例で説明する。`title`、`movie_companies`、`company_name` などのテーブルを結合して「2000年代に作品を出した日本企業はどこか」を調べるような SQL を考えると、同じ結果にたどり着くにしても join の順序や join algorit

papoo.work

PlanetScaleが出した「Neki」は、Postgresをそのまま分散させる試みだ

PlanetScaleが、sharded Postgres をうたう「Neki」をplatform previewとして公開した。単に「Postgresをもっと速くした」と言っているのではなく、1台のマシンの限界にぶつかる前提で、最初から分散運用できる形に作り直した、という話だ。元記事はかなり技術寄りだが、要するに既存のPostgresアプリを大きく壊さずにスケールさせたい人向けの新しい選択肢を出した、というニュースである。しかもPlanetScaleは、これをMySQLで培った分散運用の知見の延長として語っている。 Nekiは、PlanetScaleが公開した sharded Postgres のプラットフォームだ。platform previewとして利用できるようになったが、記事でははっきり「この段階のNekiで本番ワークロードは走らせるべきではない」と注意している。まだ変化が大きく、壊れる変更もありうるからだという。 PlanetScaleによれば、Nekiは同社が8年間かけて運用してきた大規模な sharded MySQL クラスタの経験から生まれた。何千もの本番ワークロード

papoo.work

データベースを「1台の箱」から解き放つ発想が面白い

Databricksのこの記事は、Postgresを土台にしたサーバーレスDB「Lakebase」と、その先にある「LTAP」という考え方を紹介しています。 話がかなり技術寄りなので、最初は「何のことだ？」となるかもしれません。でも中身はわりとシンプルで、ひと言でいえばデータベースの“保存のしかた”を根っこから見直そうという話です。 いま多くのデータベースは、書き込みログも実データも、だいたい1台のマシンの中で抱え込んでいます。この記事はそこを「そもそも古くないか？」と疑い、クラウド時代に合う形へ組み替えています。ここがかなり面白い。 しかも単なる理想論ではなく、書き込みの安全性、読み取りの拡張、障害対策、分析処理との干渉まで一気に整理しているのがポイントです。 伝統的なデータベースは、WAL（書き込みログ）と data files（実データ）を1台のマシンに持つ「monolith」になりがち その構造だと、データ消失のリスク、read replica の高コスト化、分析処理による遅延が起きやすい Lakebase は Postgres の compute を stat

papoo.work

SQLiteだけで十分な durable workflows の話

この記事は、「durable execution（壊れにくい実行）」には、必ずしも巨大な基盤は要らないと主張しています。 DBOS が「Postgres があれば十分」と言った流れに対して、Obelisk は「もっと進めて、SQLite でも多くのケースで十分では？」と提案しています。 重要なのは 計算処理そのもの ではなく、workflow の状態を安全に残すこと だ、という考え方です。 SQLite は単体で transactional な永続性を持てるので、余計な DB サービスを増やさずに済みます。 Litestream を使えば、SQLite の変更を S3 互換の object storage に非同期でバックアップできます。 ただしこれは高可用性の共有DBの代わりではなく、多少の遅延や一部データ喪失の可能性を許容する設計です。 AI agents や実験的な workflow には、Postgres より SQLite のほうがシンプルで相性がいい場面が多い、というのがこの記事の見立てです。 「durable workflows を作るのに、最初から大げさ

papoo.work

Postgresだけで耐障害ワークフローを回すという発想がかなり面白い話

DBOSは、Postgresを使って durable execution（途中で落ちても再開できる実行方式）を実現しよう、という考え方を紹介している 従来は Temporal や Airflow、AWS Step Functions のような外部の orchestrator（司令塔）がワークフローを管理する DBOSの記事は、「そもそもデータベースが司令塔になればよくない？」という発想を押し出している Postgresに進捗を checkpoint（保存）すれば、クラッシュしても最後の保存地点から再開できる 可観測性（observability）は、PostgresのテーブルをSQLで見るだけでかなり強力に実現できる 既存システムがすでにPostgresを使っているなら、新しい中枢システムを増やさずに済むのが大きなメリット まず、ここがいちばん大事です。 durable execution は、ざっくり言うと「処理の途中経過をちゃんと保存しておいて、落ちても続きからやり直せる仕組み」のことです。 ゲームでいうセーブポイントみたいな

papoo.work

PS5の配信をTwitchのふりで受け取るまで

PS5の画面共有をDiscordに回したいのに、標準機能だけでは思うようにいかない。そんな不便を、ある開発者がかなり遠回りな方法で突破した話だ。単なる裏技紹介ではなく、PS5が配信先をどう決めているのかをDNSとRTMPの側からほどいていくのが面白い。ソニーのプラットフォーム制限が強まる中で、どこに穴があり、どこでつまずくのかもよく見える。 元記事の筆者は、友人とDiscordでゲーム配信を見せ合うことが多いが、PS5にはDiscordへ直接画面共有する手段がない、と書いている。そこで最初に思いつくのはキャプチャカードだ。HDMI出力をカードに入れ、Mac上のOBSで再配信するやり方である。ただし、まともな製品は100ドルを超えることもあり、そこまでお金をかけたくなかったという。 次に試したのがRemote Playだった。PS5をMacBookにつないで、そのMacの画面をDiscordに流す方法だ。これは一応動くものの、コントローラーやイヤホンなどをRemote Play側に付け替える必要があり、入力遅延も時々気になる。しかも画質や配信条件はPS5側に握られていて、細かく調整できな

papoo.work

AI研究所に「説明責任」を求めるべきだというCal Newportの主張

最近のAI業界では、技術そのものよりも、AI企業の振る舞いのほうが議論を呼んでいる。Cal Newportは今回、OpenAIとAnthropicの動きを見て「何が起きているのかを調べる段階に入った」と強く主張した。単なる賛否ではなく、どんな研究を誰がどんな意図で進めているのかを、外から確かめる必要があるという話だ。読んでいて印象に残るのは、彼がAIの能力よりも、フロンティア企業の態度に不信感を向けている点である。 元記事でCal Newportが取り上げているのは、ここ数か月のOpenAIとAnthropicの振る舞いだ。彼によれば、まずOpenAIが、LLMを使ったエージェントシステムがどれだけ不穏で強力かを印象づけるような発表や報道を、計算された形で続けた。次にAnthropicの社員たちが、こうした技術が人類滅亡につながる確率を公開の場で議論し始めた。しかもその語り口が妙に落ち着いていて、どこか「避けられない流れだ」と受け入れているように見えた、というのが彼の受け止めだ。 さらに追い打ちをかけたのが、Anthropic CEOのDario Amodeiが出した「We Must

papoo.work

AIに「速く考える」と「ゆっくり考える」を持たせる試み

AIはここ数年でずいぶん賢くなりましたが、できることはまだ狭い範囲に偏っています。画像認識や翻訳、分類や予測のように、得意分野ごとに強くなる一方で、人間が自然にやっている「状況を見て、考え直して、別のやり方を探す」といったふるまいはまだ弱い。arXiv に載ったこの論文は、そこを埋める手がかりとして metacognition、つまり自分の状態や能力を見ながら考え方を切り替える仕組みに注目している。単なる新しいモデル提案というより、AIにどんな“考え方”を入れるべきかを、人間の認知科学から引き直そうとする話だ。 この論文の題名にある “Thinking Fast and Slow” は、心理学者ダニエル・カーネマンの有名な枠組みを指している。人間の思考には、直感的で反射的に動く system 1 と、時間をかけて熟考する system 2 がある、という考え方だ。著者たちはこの見方を AI に持ち込み、問題が来たときにまず速い担当者が過去の経験を使って処理し、必要なときだけ遅い担当者が前に出てきて推論や探索を行う multi-agent architecture を提案している。 ここ

papoo.work