Bug: dates shift when Accounter is used from a different timezone
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- graphql, postgresql, typescript
- Domain
- api, databases, full-stack, testing-qa
Research direction
Start with packages/server/pgconfig.json, packages/server/src/modules/common/typeDefs/common.graphql.ts, and packages/server/src/shared/helpers/misc.ts, then trace date-only fields through providers, resolvers, GraphQL, client code, mutations, and filters. Audit parsing and formatting under TZ=America/New_York, TZ=Asia/Tokyo, and TZ=UTC. Done means date-only values remain stable across timezones, datetime handling is explicit, and tests cover the identified paths.
Written by the indexing model from the issue text.
Description
Problem
Several users who open Accounter from a different timezone see wrong dates. A common case is the document date: it is a date-only value (yyyy-mm-dd, no time), so it should not depend on timezone at all, yet it can show up a day early or late depending on where the user is.
Reference (Slack): https://guild-oss.slack.com/archives/D01DQ8VJ8KX/p1790560716338549
Suspected cause
Date-only values are likely converted to a JS Date (a point in time, which carries timezone) somewhere between the DB and the UI. Serializing or formatting that Date in another timezone then moves it to the neighbouring day. Some places this could happen:
- DB → server: pgtyped has no type overrides in
packages/server/pgconfig.json, so Postgresdatecolumns come back as JSDate, not as strings. - Server → GraphQL: the
TimelessDateandDateTimescalars (packages/server/src/modules/common/typeDefs/common.graphql.ts) and the helpers inpackages/server/src/shared/helpers/misc.ts(dateToTimelessDateString,timelessDateStringToLocalDate, …) depend on the server's local timezone. - GraphQL → client: the client may call
new Date('yyyy-mm-dd'), which JS reads as UTC midnight, and then format it in the browser's local timezone. - Client → server (mutations/filters): date pickers and filters may send a local-midnight
Date/ISO string where the server expects a date-only value.
Scope
Trace every date (yyyy-mm-dd) and datetime field through the whole system, DB → providers → resolvers/scalars → GraphQL → client → UI and back through mutations and filters, and make sure each is handled correctly and consistently:
- List the date-only fields (document date, transaction/value/event dates, VAT/report periods, etc.) and the true datetime fields.
- Keep date-only values as
TimelessDateStringend to end, never going through a timezone-awareDateunless that is explicit and safe. - Make datetime values explicit about timezone (UTC in transit, local time only at display).
- Audit the client for
new Date(<date-only string>)and for date formatting/parsing in pickers and filters. - Add tests that run under different
TZvalues (e.g.TZ=America/New_York,TZ=Asia/Tokyo,TZ=UTC) to lock in stable behaviour.
Related
- #1924: treat DB
DateasTimelessDateString(pgtyped type override). This is probably part of the fix. - #1734, #86, #13: earlier timezone and date-string issues (closed).
- Dominant language
- TypeScript
- Stars
- 30
- Forks
- 8
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 182
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Urigo/accounter-fullstack
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Urigo/accounter-fullstack#4604 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Urigo/accounter-fullstack#4580 ·
Maintainers usually reply within 1 day
-
Document PG18 migration conventions: NOT NULL NOT VALID, and generated columns default to VIRTUALOpen
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Urigo/accounter-fullstack#4366 ·
Maintainers usually reply within 1 day
-
Harden Deel invoice contract ID normalizationPossibly taken @gilgardosh claimed this 1 day ago. Open
Urigo/accounter-fullstack#4747 · 1 assignee ·
Maintainers usually reply within 1 day
-
Client: document image viewer (DocumentImageDrawer) shows the image too smallPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Urigo/accounter-fullstack#4685 ·
Maintainers usually reply within 1 day
All issues in Urigo/accounter-fullstack
Similar issues
-
engine-rs P3 review-deferral wasm
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
maniator/verticopolis#1154 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
telerik/kendo-react#3861 ·
Maintainers usually reply within 1 day
-
[bug]: use-mobile.ts uses pixel logic, causing UI state de-sync with Tailwind CSS rem breakpointsOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
task
Difficulty 2/5 1-3 hours Newbie friendliness 72/100