Split out of #537 (closed), which assumed this already existed and it does not. Recorded rather than
left to rot in a closed issue, per the repo's own rule that an unmet acceptance criterion becomes a
follow-up issue or a written won't-fix.
What #537 claimed
Its body stated that the #264 AGENTS.md bullet was stale because "provision-account now takes a
timezone at creation".
What is actually shipped (verified 2026-08-25)
provision-account accepts --name --slug --owner-email --locale --currency
(src/Cluckwork.Api/Cli/ProvisionAccountCliCommand.cs:15-19), and AccountProvisioner.ProvisionInput
(src/Cluckwork.Infrastructure/Identity/AccountProvisioner.cs:180-185) has no timezone field. There is
no timezone flag.
A newly provisioned farm therefore starts on whatever the account default is, and its owner sets the real
zone in Settings after first login — which is exactly the #264 behaviour the epic described for the
default account.
Why it might be worth adding
#264 is load-bearing: the clock resolves IANA zones via TimeZoneInfo.FindSystemTimeZoneById and fails
closed, and every date the farm sees depends on it. An operator provisioning a farm in another region
already knows its timezone at creation time; making them wait for the Owner's first login means the farm's
first day of data is recorded against the wrong zone.
Why it may not be worth adding
The farm's Owner sets it in Settings on first login, and until then no data exists to be misdated. The
current behaviour is not broken — it is just later than it could be.
If built
Not a blocker
Epic #530 is substantially shipped without it, and #537 closed with this recorded as deliberately not met.
Split out of #537 (closed), which assumed this already existed and it does not. Recorded rather than
left to rot in a closed issue, per the repo's own rule that an unmet acceptance criterion becomes a
follow-up issue or a written won't-fix.
What #537 claimed
Its body stated that the
#264AGENTS.md bullet was stale because "provision-accountnow takes atimezone at creation".
What is actually shipped (verified 2026-08-25)
provision-accountaccepts--name --slug --owner-email --locale --currency(
src/Cluckwork.Api/Cli/ProvisionAccountCliCommand.cs:15-19), andAccountProvisioner.ProvisionInput(
src/Cluckwork.Infrastructure/Identity/AccountProvisioner.cs:180-185) has no timezone field. There isno timezone flag.
A newly provisioned farm therefore starts on whatever the account default is, and its owner sets the real
zone in Settings after first login — which is exactly the #264 behaviour the epic described for the
default account.
Why it might be worth adding
#264 is load-bearing: the clock resolves IANA zones via
TimeZoneInfo.FindSystemTimeZoneByIdand failsclosed, and every date the farm sees depends on it. An operator provisioning a farm in another region
already knows its timezone at creation time; making them wait for the Owner's first login means the farm's
first day of data is recorded against the wrong zone.
Why it may not be worth adding
The farm's Owner sets it in Settings on first login, and until then no data exists to be misdated. The
current behaviour is not broken — it is just later than it could be.
If built
--timezoneonprovision-account, optional, defaulting to today's behaviour.TimeZoneInfo.FindSystemTimeZoneByIdat the CLI boundary, not at first use —Deploy: farm timezone provisioning — seeded UTC + undocumented tzdata/ICU image dependency #264's whole point is that an unresolvable zone fails closed, and a provisioning command is the right
place to fail loudly rather than leaving a farm that breaks on its first date render.
#264bullet inAGENTS.mdonly when this actually ships — it currently describes thereal behaviour correctly, and Docs: multi-farm tenancy ADR + AGENTS.md / GLOSSARY sync #537 was corrected rather than "fixed" precisely because the bullet was
right and the issue was wrong.
Not a blocker
Epic #530 is substantially shipped without it, and #537 closed with this recorded as deliberately not met.