コンシェルジュ #122
ツッコミ矛盾・抜けを指摘。必要なら既存の検証経路に提案を渡します。
調査公開の場所名・組織名・一般話題を下調べしてまとめます。
ページ生成「◯◯をページにまとめて」で読み物を作り /adhoc に置きます。
日時のズレ（datetime）の束って、候補の日時で一括OKにしても大丈夫そう？
スチュワード不在(このPCが起動していません)。メッセージは残せます — 起動後にまとめて読み、返信します。
(最終heartbeat 5878 秒前)
あなた
2026-07-19 06:01
日時のズレ（datetime）の束って、候補の日時で一括OKにしても大丈夫そう？方針を相談したい。
スチュワード
2026-07-19 06:04
いい質問です。結論から言うと、**この束は「一括で候補を採用」するのは慎重になった方がいい**ケースです。
## 束の中身: `datetime:oiso-minute-overflow`（10件）
| queue_id | moment | when_raw | 候補①(−60) | 候補②(現状維持) |
|---|---|---|---|---|
| 180 | MMT-777 | 10:**60** | 10:00 | day精度のまま |
| 181 | MMT-778 | 10:**61** | 10:01 | day精度のまま |
| … | … | … | … | … |
| 189 | MMT-786 | 10:**69** | 10:09 | day精度のまま |
全10件が 2024-05-24・oiso データセット・legacy_id 106〜115 の連番。
## 判断のポイント
**−60 仮説が正しい場合**: 元データの時刻入力で「分」に +60 のオフセットがかかっていた → 10:00〜10:09 が本来の時刻。
**しかし再調査(2026-07-11)が指摘している不確実性**:
- 「別カウンタの取り違えの疑い」もある — つまり 60〜69 は時刻ではなく連番IDが紛れ込んだ可能性
- confidence = 0.5（どちらとも言えない）
- 「分の一意確定は不可のため 0.85 未満」と明記
**現状(day精度)の安全性**:
- ETL が不正時刻を捨てて `occurred_time=NULL`・`date_precision=day` で格納済み
- **データ破損はゼロ**。when_raw（生値）も保存されている
- 実害なし
## 私の見立て
- **候補②「変更しない(day精度のまま)」で10件一括OK** → 安全。情報は失わず、間違った時刻を入れるリスクもない。
- **候補①「−60 で分精度に昇格」で一括OK** → 仮説としてはもっともらしいが、「連番取り違え」の可能性を棄却する根拠がない。あとで間違いだったとき、戻す手間が出る。
つまり「候補の日時(−60)で一括OK」は**やめた方がいい**。やるなら「現状維持(keep-day)」で一括OKが無難です。
---
心当たりありますか？ 2024-05-24 の oiso で、10件のイベントを10:00〜10:09 に連続で記録した覚えがあれば −60 仮説が確定しますし、逆に「連番で入力しただけ」なら day 精度のままが正解です。