From 4b29fafcff047ad7695cbb0fba7f8e4e32aef9f9 Mon Sep 17 00:00:00 2001 From: kjh2064 Date: Sun, 12 Jul 2026 01:29:14 +0900 Subject: [PATCH] fix: Use KST (Asia/Seoul) instead of UTC for release date component User caught this directly: it's already 2026-07-12 in Korea, but Run #2008's release was tagged quant_20260711.3.7150737 -- the wrong date. Confirmed: UTC was still 2026-07-11 16:2x when KST was already 2026-07-12 01:2x (9-hour offset). prepare-release.yml computed TODAY via `TZ=UTC date +%Y%m%d`, which is only "correct" if the team operates on UTC -- but this project's production server logs, deployment cadence, and team are all Korea Standard Time. Any release cut between midnight and 9am KST would silently tag itself with yesterday's date. Fixed by using `TZ=Asia/Seoul date +%Y%m%d` instead. --- .gitea/workflows/prepare-release.yml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.gitea/workflows/prepare-release.yml b/.gitea/workflows/prepare-release.yml index a9631fcd..599dc31a 100644 --- a/.gitea/workflows/prepare-release.yml +++ b/.gitea/workflows/prepare-release.yml @@ -39,7 +39,13 @@ jobs: # Auto-generate version if not provided if [ -z "$VERSION_INPUT" ]; then - TODAY=$(TZ=UTC date +%Y%m%d) + # This project operates on Korea Standard Time (production + # server logs, ops schedule, and the team are all KST) -- + # using UTC here silently rolled the date back by up to 9 + # hours (e.g. 2026-07-12 01:xx KST is still 2026-07-11 16:xx + # UTC), so a release cut right after midnight KST would tag + # itself with yesterday's date. + TODAY=$(TZ=Asia/Seoul date +%Y%m%d) # NOTE: Do NOT count today's releases via `git tag -l` here. # actions/checkout@v4 defaults to a shallow, single-branch