My Unattended Task Was Overwriting the Previous Day's Log — the Container's date Was Returning UTC

One morning I went to check the previous day's log, and stopped.

I opened 2026-06-13.txt and the overnight batch entry that should have been there was gone. In its place sat a single line written by that morning's run. The file existed. Only its contents had been swapped out.

My first thought was that the task had double-fired and one copy had corrupted the other. But the real cause turned out to be far more ordinary: the date command inside the container.

Running several sites unattended as an indie developer, I've come to fear this category of bug the most — the kind where data quietly disappears. If something errors out, I notice. When it gets silently overwritten, I can't even tell anything was lost.

What was actually happening — the log wasn't deleted, it was written under a different date

Each run of my scheduled task left a date-stamped log. The skeleton looked like this:

LOG_DIR="$WS/_updated_article_log/claudelab"
echo "[$(date +%H:%M)] Published one article: $TITLE" > "$LOG_DIR/$(date +%F).txt"

On my local Mac, this was flawless. The Mac's timezone is Japan time.

It broke the moment I moved the same script to an unattended run on a cloud container. A container's default timezone is UTC — nine hours behind Japan. So a task that fires at 08:00 Japan time is still at 23:00 the previous day in UTC.

# The task starts at 2026-06-13 08:00 Japan time
$ date
Thu Jun 12 23:00:00 UTC 2026   # inside the container it is still "the 12th"
 
$ date +%F
2026-06-12                      # meant to be today, but it is yesterday

A second trap compounded it: I was using > (overwrite) for the redirect.

The morning task computed the filename for "the 12th," opened it with >, wiped out the perfectly good log written the night before, and then wrote its own single line. The log wasn't deleted. It was written to the wrong day's file, in overwrite mode. That was the whole story.

What I suspected first, and the real cause

I suspected a double-fire first — that the scheduler had launched the same task twice and they had collided.

But the run history showed exactly the expected number of launches per day. No sign of a collision.

Next I suspected filesystem sync. Because I was writing through a cloud-synced folder, maybe a sync delay had resurrected an older version. Comparing local and remote timestamps ruled that out too.

The decisive clue was the mismatch between a file's name and its contents. What should have been 2026-06-13.txt had landed inside 2026-06-12.txt. Exactly one day off. The instant I remembered the nine-hour offset, everything lined up.

What helped during isolation was checking what the script actually outputs once, before piling on more guesses.

# Inside the container, print the date the script sees
$ TZ=Asia/Tokyo date +%F
2026-06-13
$ date +%F
2026-06-12

Two different values. That confirmed the hypothesis. The problem wasn't which line of code to change — it was what date was returning.

The permanent fix — pin the timezone, append, and make the failure visible

I fixed it in three layers, because one alone felt insufficient.

First, make the date calculation explicit about its timezone. This addresses the root cause.

# Bad: depends on the container default (UTC)
DAY="$(date +%F)"
 
# Good: pin it to Japan time
DAY="$(TZ=Asia/Tokyo date +%F)"

Declaring export TZ=Asia/Tokyo once at the top of the script applies to every later date call. It removes the chance of forgetting it per task, which is why I prefer it.

#!/usr/bin/env bash
set -euo pipefail
export TZ=Asia/Tokyo   # the moment this line exists, every later date is Japan time
 
LOG_DIR="$WS/_updated_article_log/claudelab"
mkdir -p "$LOG_DIR"

Second, stop overwriting and append instead, so multiple runs on the same day stack up rather than clobber each other.

# Bad: the second run of the day erases the first
echo "[$(date +%H:%M)] $MSG" > "$LOG_DIR/$DAY.txt"
 
# Good: accumulate the day's entries
echo "[$(date +%H:%M)] $MSG" >> "$LOG_DIR/$DAY.txt"

Even if a future version of me forgets the timezone fix, appending means an entry can land in the wrong day's file — but it can no longer delete an existing record. The idea is to lower the worst-case blast radius.

Third, make anomalies detectable. The best defense against a bug that breaks silently is to refuse to let it stay silent.

# Confirm today's log is non-empty after the run
DAY="$(TZ=Asia/Tokyo date +%F)"
LOG="$LOG_DIR/$DAY.txt"
 
if [ ! -s "$LOG" ]; then
  echo "WARN: today's log ($DAY) is empty. Check the timezone or the write path." >&2
fi
 
# Sanity-check that the latest entry's hour is close to now
head -1 "$LOG" | grep -q "$(TZ=Asia/Tokyo date +%H)" ||   echo "NOTE: the latest log time is far from the current time" >&2

The mindset of watching an unattended task from the outside is something I also wrote about in noticing when scheduled generation silently fails to fire. This log-overwrite was one species of that "failure you can't notice."

Why it never reproduced locally, not once

What made this bug nasty was that it simply cannot happen in the development environment.

My Mac's timezone is Japan time. Both date and date +%F always return the correct day. No matter how many times I tried, it wouldn't reproduce. Yet the instant I moved it to an unattended container, an invisible assumption — the environment's timezone — changed, and the same code behaved differently.

The lesson I took away: for anything time-dependent, never leave "which timezone do we run in" up to the environment. When local and container disagree on an implicit assumption, the bug slips past your tests and breaks only in production.

For the same reason, other traps split behavior between container and laptop. The case where a stale clone becomes the basis for a decision is in refreshing a shallow clone before it informs a decision, and the other side — what to do when an unattended task quietly stops — is in why Cowork scheduled tasks go quiet and how to auto-recover.

One more point that is easy to conflate. The scheduler firing "at 08:00 Japan time" and the shell it launches having date return Japan time are two separate things. Even with a correct trigger time, if the shell itself is still on UTC, you get the very same drift. The trigger time and the timezone your script uses to compute dates have to be aligned independently.

Keeping myself from the same rut next time

Whenever I write a script that uses the clock, I now check one line before pushing.

# Does "the environment's date" disagree with "the intended timezone's date"?
diff <(date +%F) <(TZ=Asia/Tokyo date +%F) && echo "OK: identical" || echo "Caution: timezone gap"

If that line prints Caution, the script is a candidate to break only inside the container. A mere nine-hour gap was enough to erase a full day of logs.

For unattended operations, I've come to believe that being able to notice when something breaks matters more than never breaking at all. If this spares even one silent data loss for another indie developer running their own fleet of automated tasks, I'll be glad.