timezone is not honored in log

[bam80]

The system has timezone set, so date shows correct time.
Still, mtg shows UTC time in log.

@dolonet Если это лишнее, могу перестать вас упоминать в новых багах.

[dolonet]

mtg writes timestamps as Unix milliseconds (zerolog.TimeFieldFormat = zerolog.TimeFormatUnixMs in internal/cli/run_proxy.go), i.e. a raw integer — there is no timezone embedded in the value. What you read as "UTC" is your log viewer (or jq's todate) rendering that integer in UTC by default. The host TZ doesn't enter the picture because mtg never formats the timestamp as a string.

This is intentional: numeric epoch is unambiguous and stable for log aggregators, and adding a TZ-aware string default would be a breaking change for anyone parsing the current format. There's no plan to change it.

If you want local time at viewing, render it on the consumer side, e.g.:

mtg ... | TZ=Europe/Moscow jq -r '.timestamp |= (./1000 | localtime | strftime("%Y-%m-%d %H:%M:%S"))'

(or use todate for ISO-8601 UTC). Closing as not-a-bug.

---

По-русски: теги ок, продолжайте — это нормальный поток багрепортов, ничего лишнего.

[bam80]

Sorry but I still do not see the point.
All the other apps apparently log properly, why mtg should be different?
I use logread, standard log viewer on OpenWrt.
podman logs for mtg.

Thanks for the suggested workaround, but it's too messy to be acceptable.

[bam80]

If TZ-aware log in not desirable by default, we could probably make it optional?

[dolonet]

Reopening — on reflection my close was too quick.

@bam80 you're right that podman logs / logread are the realistic consumers for an embedded setup, and piping every line through jq is not a fix. The fair read of your follow-up is "keep the default, but let me opt into a TZ-aware format", and that's reasonable.

Sketch of what I'd be willing to land: a single optional knob (env var MTG_LOG_TIME_FORMAT, accepting unix-ms (current default), unix, or rfc3339). rfc3339 would honor the host TZ. No change to the default, no new required config field — just an escape hatch for cases like yours. zerolog supports this directly, so the diff is small.

@9seconds — your call. I'd lean towards accepting it as an env-only opt-in (no config.toml surface), but config surface is your domain; I won't merge this without your sign-off. If you'd rather keep the log format strictly numeric for aggregator stability, also a valid answer and I'll re-close.

[9seconds]

I think we can add a separate option to configure log format in this case. My personal take is that is usually simpler to work with unix timestamps, because they universally imply UTC timezone but I do see a point on OpenWRT specifics. If it is limited to tailing on a logfile, then yeah, it would be messy. Let's have such configuration in a config file.

#427

[dolonet]

Thanks. Before settling on a shape I checked how other Go projects with JSON logs handle this — Caddy and Promtail both accept "preset name OR free-form Go layout string" as a single config value, and zerolog (what mtg already uses) supports exactly that natively: TimeFieldFormat treats UNIXMS/UNIXMICRO/UNIXNANO/"" as magic constants and anything else as a Go reference-time layout.

Proposal: one new field logTimeFormat (string, default "unix-ms" → no behavior change). Presets map to zerolog's Unix constants or time.RFC3339/time.RFC3339Nano; anything else passes through as a Go layout. Implementation is ~15 lines — a switch with a default branch.

Example config, with commented presets for discoverability:

# logTimeFormat configures the timestamp format in logs.
#
# Numeric presets (good for log aggregators):
#   "unix-ms"      Unix milliseconds.  DEFAULT. 1773860541790
#   "unix"         Unix seconds.       1773860541
#   "unix-nano"    Unix nanoseconds.   1773860541790000000
#
# Human-readable presets (honor host TZ):
#   "rfc3339"      2026-05-20T15:23:45+03:00
#   "rfc3339-nano" 2026-05-20T15:23:45.123456789+03:00
#   "iso8601"      2026-05-20T15:23:45.123Z (always UTC)
#
# Or any Go time layout. Reference moment: Mon Jan 2 15:04:05 MST 2006.
# Examples:
#   logTimeFormat = "2006-01-02 15:04:05"               # 2026-05-20 15:23:45
#   logTimeFormat = "2006-01-02 15:04:05.000 -0700"     # with ms and offset
#   logTimeFormat = "02 Jan 2006 15:04:05 MST"          # 20 May 2026 15:23:45 MSK
#
# logTimeFormat = "unix-ms"

Default stays unix-ms — nobody parsing the current numeric format breaks. The RFC3339 / Go-layout variants pick up the host's TZ, which is what #515 and #427 actually need.

OK to proceed on these lines? If you'd rather have a different key name (e.g. nested [log] timeFormat) or a smaller preset set, happy to trim before the PR.