Self-hosted personal finance application.
test(models): build edit scope boundaries in the time zone under test
- pull request
- mayswind/ezbookkeeping#678
- language
- Go · MIT
- diff
- 1 file, +4 -4
- status
- merged 2026-09-17
GitHub API, read 2026-09-21 09:10 UTC, at render
Problem
- The tests pass a fixed zone, built from the server's current UTC offset, into CanEditTransactionByTransactionTime.
- They build the expected boundary in time.Local.
- Where a DST transition sits between that boundary and today, the two differ by an hour and the assertion fails.
- A runner in UTC never reports this.
Measurement
| TZ | before | after |
|---|---|---|
| UTC | ok | ok |
| Europe/Berlin | ScopeIsThisYearOrLater | ok |
| America/New_York | ScopeIsThisYearOrLater | ok |
| Asia/Kolkata | ok | ok |
| Australia/Sydney | ScopeIsThisYearOrLater | ok |
| America/Santiago | ScopeIsThisMonthOrLater | ok |
| Pacific/Auckland | ScopeIsThisYearOrLater | ok |
| Pacific/Chatham | ScopeIsThisYearOrLater | ok |
| America/Sao_Paulo | ok | ok |
| Asia/Kathmandu | ok | ok |
- Which test fails depends on where the transition falls. Santiago moved its clocks on 6 September, inside the current month, so there the month boundary misses rather than the year boundary.
- Zones without daylight saving time pass either way.
- -count=1 matters: without it the cached result of an earlier run is reported for every subsequent zone, because the time zone is not part of the cache key.
Rejected alternative
- Setting timezone to time.Local makes the tests pass just as well, measured in UTC, Europe/Berlin, America/Santiago and Pacific/Chatham.
- It changes what is under test. GetClientTimezone() returns a fixed zone whenever the request carries only X-Timezone-Offset and no X-Timezone-Name, and these tests are the ones covering that path.
Environment
| item | value |
|---|---|
| Go | 1.27.1 darwin/arm64 |
| branched from | b2a3f4ed |
| rest of the suite | go test ./... passes in UTC, Europe/Berlin, America/Santiago |
| diff | 1 file, +4 -4 |