DB_DUMP_BEGIN should respect container timezone (TZ environment variable)

[padixa]

Current Behavior

When setting a timezone in the container (via TZ environment variable or /etc/localtime volume mount), the DB_DUMP_BEGIN time is still interpreted as UTC time, not local time.

Example configuration:

environment:
  TZ: Asia/Shanghai
  DB_DUMP_BEGIN: "0400"  # Expected: 04:00 Shanghai time

Actual result:

Backup runs at UTC 04:00 = Shanghai 12:00 (8 hours later than expected)
Filename includes timezone offset: db_backup_2026-03-12T12:00:38+08:00.tgz

Expected Behavior

When TZ is set, DB_DUMP_BEGIN should be interpreted in the container's local timezone, not UTC.

Expected result:

• Backup runs at Shanghai 04:00 (as configured)
• Filename reflects local time: db_backup_2026-03-12T04:00:38+08:00.tgz

Workaround

Currently, users must manually calculate UTC offset:

environment:
  TZ: Asia/Shanghai
  DB_DUMP_BEGIN: "2000"  # UTC 20:00 = Shanghai 04:00 (next day)

This is confusing and error-prone, especially during daylight saving time changes.

Proposed Solution

Parse DB_DUMP_BEGIN using the container's local timezone when TZ is set:

// In pkg/core/dump.go or scheduler
var loc *time.Location
if tz := os.Getenv("TZ"); tz != "" {
    loc, _ = time.LoadLocation(tz)
} else {
    loc = time.UTC
}
// Parse DB_DUMP_BEGIN in the local timezone

Environment

Image: databack/mysql-backup:latest
Docker Compose configuration with TZ=Asia/Shanghai
Observed in production environment

[deitch]

Didn't #490 (along with some others) address this?

[padixa]

Thanks for the response! However, I think #490 only fixed the container's timezone display (i.e., date command shows correct local time), but the issue I'm describing is different.

DB_DUMP_BEGIN still parses the time as UTC regardless of the TZ setting.

Example:

environment:
  TZ: Asia/Shanghai
  DB_DUMP_BEGIN: "0400"  # Intended: 04:00 Shanghai time

Result: Backup runs at UTC 04:00 = Shanghai 12:00, not 04:00.

I verified this by checking the container logs:

time="2026-03-12T12:00:38+08:00" level=info msg="beginning dump..."

The container clock is correct (CST), but the scheduling logic still interprets DB_DUMP_BEGIN as UTC.

Workaround for now: Using DB_DUMP_BEGIN: "2000" (UTC 20:00 = Shanghai 04:00 next day), but this is confusing and error-prone.

Could the scheduler be updated to parse DB_DUMP_BEGIN using the local timezone when TZ is set?