Timezone Settings

All timestamps in the reconciliation portal and CSV exports follow the timezone selector next to the month picker at the top of the Reconciliation page. By default, this is set to your browser's locale timezone.

The Timezone Selector

Click the timezone pill (e.g. "Amsterdam") to choose from the available options. This adjusts:

• Which transactions fall within the selected month. For example, a transaction at 23:30 UTC on Jan 31 would appear in February if you're viewing in a UTC+2 timezone
• The displayed timestamps in the portal and in CSV exports

Month Boundaries Shift with Timezone

The same transaction can land in different months depending on which timezone you select. Here is an example with a transaction processed at 2025-11-01 00:30 UTC, right after midnight:

block-beta
    columns 4
    space:4

    block:header:4
        h["Transaction at 2025-11-01 00:30 UTC"]
    end

    space:4

    block:utc:1
        u1["UTC"]
        u2["00:30 Nov 1"]
        u3["November"]
    end

    block:ams:1
        a1["Amsterdam +1"]
        a2["01:30 Nov 1"]
        a3["November"]
    end

    block:ny:1
        n1["New York -5"]
        n2["19:30 Oct 31"]
        n3["October"]
    end

    block:la:1
        l1["Los Angeles -8"]
        l2["16:30 Oct 31"]
        l3["October"]
    end

    style utc fill:#d4edda,stroke:#28a745
    style ams fill:#d4edda,stroke:#28a745
    style ny fill:#fff3cd,stroke:#ffc107
    style la fill:#fff3cd,stroke:#ffc107

The transaction appears in November for UTC and Amsterdam, but in October for New York and Los Angeles. This is because those cities are still on October 31 when midnight UTC passes.

DST Crossing: How March Works in Amsterdam

Daylight saving time (DST) creates a tricky situation when the clock change happens mid-month. Amsterdam switches from CET (UTC+1) to CEST (UTC+2) on the last Sunday of March.

gantt
    title March 2026 Amsterdam - DST switch on March 29
    dateFormat YYYY-MM-DD
    axisFormat %b %d

    section Actual Offset
    CET winter UTC+1        :active, cet, 2026-03-01, 2026-03-29
    CEST summer UTC+2       :crit, cest, 2026-03-29, 2026-04-01

    section CSV Export Offset
    Entire export uses CET  :done, export, 2026-03-01, 2026-04-01

    section Key Dates
    Month start             :milestone, m1, 2026-03-01, 0d
    Clocks forward          :milestone, dst, 2026-03-29, 0d
    Month end               :milestone, m2, 2026-04-01, 0d

NjiaPay locks the export to the offset at the start of the month (March 1 = CET, UTC+1). This means:

• A transaction on March 15 at 14:00 UTC is exported as 15:00 CET (UTC+1)
• A transaction on March 30 at 14:00 UTC is also exported as 15:00 CET (UTC+1), even though the wall clock in Amsterdam actually reads 16:00 CEST at that moment

This avoids two problems:

1. A "missing hour" in your spreadsheet when clocks spring forward (2:00 AM jumps to 3:00 AM)
2. SUMIFS or pivot tables that suddenly group the same day into two different offsets

DST Crossing: How November Works in New York

New York switches from EDT (UTC-4) to EST (UTC-5) on the first Sunday of November. The same "lock to start of month" rule applies.

gantt
    title November 2025 New York - DST switch on November 2
    dateFormat YYYY-MM-DD
    axisFormat %b %d

    section Actual Offset
    EDT summer UTC-4        :active, edt, 2025-11-01, 2025-11-02
    EST winter UTC-5        :crit, est, 2025-11-02, 2025-12-01

    section CSV Export Offset
    Entire export uses EDT  :done, export, 2025-11-01, 2025-12-01

    section Key Dates
    Month start             :milestone, m1, 2025-11-01, 0d
    Clocks fall back        :milestone, dst, 2025-11-02, 0d
    Month end               :milestone, m2, 2025-12-01, 0d

November 1 is in EDT (UTC-4), so the entire November export uses UTC-4:

• A transaction on Nov 1 at 18:00 UTC is exported as 14:00 EDT (UTC-4)
• A transaction on Nov 15 at 18:00 UTC is exported as 14:00 EDT (UTC-4), even though the wall clock in New York reads 13:00 EST at that point

How the Month Boundary Works at DST Edges

The trickiest scenario is when a DST change happens on or around the 1st of a month. Here is what happens with the March/April boundary in Amsterdam:

flowchart TB
    TX[Transaction at 2026-03-31 23:30 UTC]

    TX --> AMS{Amsterdam selected}
    TX --> UTC{UTC selected}

    AMS --> CALC1[March offset = CET UTC+1\n23:30 + 1h = 00:30 Apr 1]
    CALC1 --> OUT_MAR[Not in March report\nLocal time is April 1]
    CALC1 --> IN_APR[Appears in April report]

    UTC --> CALC2[23:30 is still March 31]
    CALC2 --> IN_MAR[Appears in March report]

    style OUT_MAR fill:#fff3cd,stroke:#ffc107,color:#333
    style IN_APR fill:#d4edda,stroke:#28a745,color:#333
    style IN_MAR fill:#d4edda,stroke:#28a745,color:#333

A transaction at 23:30 UTC on March 31 falls into different months depending on the timezone:

• In UTC: it's still March 31, so it appears in the March report
• In Amsterdam (CET+1): it becomes April 1 at 00:30, so it falls out of March and into April

No transaction is ever lost. It always appears in exactly one month's report. But which month depends on your timezone selection.

Default Behaviour

If you never touch the timezone selector, it defaults to your browser's locale timezone. This means:

• A team member in Johannesburg sees timestamps in SAST (UTC+2)
• A team member in London sees timestamps in GMT/BST
• Both see the same underlying data, just grouped and displayed differently

Recommendations

1. Pick one timezone for your team and stick with it for all reconciliation work. This prevents the same transaction from appearing in different monthly reports for different people.
2. Use UTC if your team spans multiple continents. It's the simplest option with no DST changes.
3. Use your head-office timezone if your team is in one location. Timestamps will match your local business hours, making it easier to correlate with operational events.