今天終於要開始處理資料了。
原本以為這件事很簡單，畢竟 timetable 上都已經寫得清清楚楚：
MITSKI
WHITE STAGE
22:10–23:40
人看到馬上就懂。
但如果之後要讓程式幫我判斷撞團、算舞台移動時間，再排出一整天的行程，就不能只丟一張 timetable 圖給它。
所以今天先來想一個很基本的問題：
一場音樂祭，到底有哪些資料是現在真的需要存的？
一想到音樂祭資料，馬上可以列出一大堆東西：
藝人介紹、國家、曲風、照片、Spotify、舞台位置、票價、場地……
但這些現在大部分都用不到。
我目前只是想先讓系統知道：
誰、幾點、在哪裡演出。
所以第一版只抓三個東西：
這是哪一個音樂祭。
{
"festival_id": "fuji-rock-2026",
"name": "FUJI ROCK FESTIVAL '26"
}
有哪些舞台。
{
"stage_id": "white-stage",
"festival_id": "fuji-rock-2026",
"name": "WHITE STAGE"
}
誰在什麼時間、哪個舞台演出。
{
"artist": "MITSKI",
"stage": "WHITE STAGE",
"festival_day": "2026-07-26",
"start_time": "22:10",
"end_time": "23:40"
}
目前先這樣。
把三個東西放在一起，大概就是下面這個關係：
簡單來說，一個 Festival 可以有很多個 Stage，一個 Stage 又會有很多場 Performance。
之後真的需要更多東西，再加。
前幾天看 FUJI ROCK timetable 的時候，就發現它有一個很有趣的地方。
過了晚上 12 點，時間不會重新寫成 00:00、01:00，而是繼續：
24:40
25:45
27:00
29:00
平常看音樂祭 timetable 完全不會覺得有什麼問題。
看到 25:45，我知道就是「這天玩到凌晨 1:45」。
但現在要把它存進程式，問題就來了：
一天哪來的 25:45？😂
一般時間格式不會接受：
25:45
所以我得把「timetable 上顯示的時間」跟「實際日期時間」分開。
例如 FUJI ROCK 7 月 26 日這天：
ICHIRO YAMAGUCHI (sakanaction)
25:45–27:00
畫面上還是照原本 timetable 顯示：
25:45–27:00
但程式裡要知道，它真正的時間其實是：
7 月 27 日 01:45–03:00
所以資料可能會變成：
{
"festival_day": "2026-07-26",
"display_start_time": "25:45",
"display_end_time": "27:00",
"start_at": "2026-07-27 01:45",
"end_at": "2026-07-27 03:00"
}
這樣使用者還是看到音樂祭原本的 25:45，不需要自己換算。
程式則拿真正的日期時間去算撞團和排序。
如果只看日曆：
7/26 23:59
↓
7/27 00:00
一天就結束了。
但音樂祭不是。
對參加 FUJI ROCK 的人來說，凌晨 1 點、3 點，甚至 5 點的演出，可能都還算「7 月 26 日這一天」的行程。
所以我需要另外保留：
festival_day
它不是單純告訴我現在是幾月幾日，而是：
這場演出屬於音樂祭的哪一天。
這個問題如果我一開始沒有真的拿 FUJI ROCK timetable 來測，大概做到後面才會發現。
另外一開始就提到的：
今天先不放進音樂祭資料裡。
因為：
MITSKI 22:10 在 WHITE STAGE 演出
這是所有人都一樣的事實。
但：
MITSKI 是我的 Must See
這是我的個人設定。
所以我先把它們分成兩邊：
音樂祭資料
Festival
Stage
Performance
跟：
使用者資料
想看的藝人
Must See / Want to See / Maybe
其他看團偏好
不然現在全部塞在一起，我自己應該會先亂掉。
所以今天最後要決定的東西其實很少。
第一版先需要：
Festival
├── Stage
└── Performance
每一場 Performance 至少知道：
藝人
舞台
Festival Day
顯示的開始時間
顯示的結束時間
真正的開始時間
真正的結束時間
目前還沒有 Firebase，也還沒有 Gemini。
明天就來試著把 FUJI ROCK 的真實 timetable 整理成第一批測試資料。
下集待續
iThome鐵人賽
看影片追技術