Time Zones in Your Sharklio Reports: Why Days Differ

What time zone do Sharklio reports use?

Sharklio reports use the time zone saved on your account. Every date and time on your Dashboard, in Reports, and in CSV exports is shown in that zone, and each day runs from midnight to midnight there. The Reporting API uses the same zone unless you send a timezone parameter, and postbacks carry no time at all. When a result sits on a different day in your own logs, the cause is almost always a different zone, a postback retry, or a page that dates a different moment.

Where to set your account time zone

The first time you open your dashboard, Sharklio saves the time zone your browser reports, unless you have already picked one. Browsers expose it through the Intl.DateTimeFormat resolvedOptions() method, which MDN describes as returning an IANA time zone name, by default the runtime’s own zone. Check the result once anyway: a laptop on a trip or a remote desktop may report a zone you do not want, and if the browser’s zone cannot be used, the account keeps a default zone until you choose one.

1. Click Account in the sidebar, under the Account heading. On a phone, tap More, then Account.
2. In the Profile section, find the Time zone row under Profile information. Its note reads: “Every date and time in your dashboard, reports and exports uses it, and your days start at midnight there.”
3. Pick your city, for example (GMT-5) New York, Toronto or (GMT+5:30) Mumbai, New Delhi, Kolkata, and click Save. If the device you are using is set to another zone, a Use this device’s time zone link offers it in one click.
4. The confirmation reads, for example, “Time zone saved. Times now show in New York time (GMT-5).” The hint under the menu shows the current time there, such as “Now 14:05, New York time (GMT-5).”

The list offers well-known cities, one for each set of clock rules, plus UTC. If your browser saved a zone that is not in the list, it stays selected under its own name. Performance, Conversions, Chargebacks, and Postbacks repeat the zone under the list, for example “Times are in New York time (GMT-5).”, with a Change link back to this setting.

What your time zone changes

The setting decides where each day starts and ends and how every time is written. It does not decide which moment a page uses to date a result. That differs by page, and it explains many “wrong day” questions:

On the Dashboard, Today starts at midnight in your zone and is compared with yesterday at the same time. The start and end of an app’s time-limited bonus are entered in your account time zone as well, and the form says so under the fields; Set up your app currency covers the rest of that tab. Messages in the support chat are dated in your zone too. For what each card and column means, see How to read your dashboard and reports.

What the setting does not change

• When anything happened. A click or a conversion keeps its exact moment. A new zone only moves the midnight lines, and your whole history is regrouped right away. Nothing is recalculated or lost, and you can switch back at any time.
• Your postbacks. None of the postback macros is a date or a time, so nothing on your server needs to change when you switch zones.
• API calls that name a zone. A request with timezone uses that zone, whatever your account says.
• Payout statements. Their periods are fixed and do not move when you change your time zone.
• A bonus you already scheduled. It still starts and ends at the same moment. The form just shows those times in your new zone.

Why a conversion shows on a different day

Your logs or tools use another zone

Servers, log tools, and tracking platforms often write UTC. With your account on New York time in winter (GMT-5), anything from 19:00 to midnight is already the next day in UTC. With the account on Kolkata time (GMT+5:30), anything from midnight to 05:30 is still the previous day in UTC. Advertisers may report in yet another zone, and Sharklio can only date a result from when the advertiser reports it, which can be later than the moment your user finished.

The pages date different moments

Conversions dates each row by when the result was recorded. The Dashboard and Performance count it when it was credited. For most results that is the same moment. Now and then a result goes through a short extra traffic check, which the Credits and reversals docs put at usually about a day. It then appears in Conversions on the day it arrived and in your Dashboard earnings on the day it was credited. Life of an offerwall conversion walks through Pending and Credited.

A reversal is dated twice

Chargebacks and the Reversed column in Performance use the day of the reversal. The Reporting API keeps a transaction on its original day and only changes its state to reversed, so a reversal on November 14 changes a day you may have closed weeks ago. Publisher earnings, settlement, and reversals explains why reversals happen.

The postback arrived later

The first postback goes out right after the credit. If your server fails or times out, the postback docs say Sharklio tries again up to 5 times, after about 1 minute, 5 minutes, 30 minutes, 2 hours, and 6 hours. A credit at 23:50 that only gets through on a retry is logged by your server after midnight.

Illustrative example: one late-evening conversion in two time zones

A publisher has the account set to New York time. Their server writes its logs in UTC. A user completes an offer on a Monday evening, and the server is restarting when the first postback arrives. Sample times only:

The publisher’s Dashboard counts the earning on November 2. Their reward ledger, written when the postback arrived, says November 3, in both zones, because the delivery came after midnight. In the API, the transaction’s credited_at reads 2026-11-02T23:52:10-05:00 with the default zone and 2026-11-03T04:52:10+00:00 with timezone=UTC. Nothing is missing: the transaction_id is the same everywhere. If the account were set to UTC instead, the click, the credit, and the delivery would all fall on November 3, and the reversal on November 15.

Daylight saving time in your reports

Your time zone is a city with its own clock rules, from the IANA Time Zone Database, which IANA says records the history of local time and the changes political bodies make to UTC offsets and daylight saving rules. So you never switch by hand:

• The offset follows the season. The GMT figures in the list and in “Times are in” are today’s offsets, so New York shows GMT-4 in summer and GMT-5 in winter.
• Change days are 23 or 25 hours long. Reports count exactly what happened between the two midnights in your zone. In the hourly view of that day, the repeated hour is one slot holding both hours, and the skipped hour stays empty.
• Pick the city with your rules, not just your offset. In winter, Denver and Arizona both show GMT-7, but NIST’s daylight saving time page notes that Arizona does not observe DST (the Navajo Indian Reservation there does). Choose Denver there and your summer days start an hour off.
• Regions change on different dates. NIST gives the US rule as 2:00 a.m. on the second Sunday of March to the first Sunday of November. The European Commission’s summer time page gives the EU rule as the last Sunday of March to the last Sunday of October. In 2026 that meant March 8 and November 1 in the US against March 29 and October 25 in the EU, so for a few weeks a year New York is 4 hours behind London instead of 5. If a partner reports in a European zone, expect their day boundary to shift against yours in those weeks (checked on November 2, 2026).

How to reconcile Sharklio reports with your server logs

1. Pick one reference zone. If your servers log in UTC, either choose (GMT+0) UTC in Account or keep your local zone in the dashboard and send timezone=UTC in your API calls. Mixing both without noting it is where most mismatches start.
2. Log your own receipt time. The postback has no timestamp, so store the time your server received it, with its offset, next to transaction_id, event_id, and the status. RFC 3339 defines that format, where 16:39:57-08:00 is local time 8 hours behind UTC.
3. Match by ID, never by time. transaction_id is the same for the credit and any later reversal. Add {event_id} to your postback URL too: the Postbacks CSV has a URL column for every attempt, so each line in your access log maps to one row. Prevent duplicate reward credits shows the ledger table to store it in.
4. Allow for lag. Your receipt time is never earlier than the credit and, after retries, can be hours later. Compare by transaction, then look at times only to explain a gap.
5. Compare daily totals through the API. Pull /v1/stats with group_by=day and your reference zone, then compare with your ledger. Use the full IANA name, such as America/New_York or Asia/Kolkata: abbreviations such as EST or GMT, and old aliases such as US/Eastern or Asia/Calcutta, are rejected with invalid_timezone. The Reporting API quick start has a ready script.
6. Label your exports. CSV times carry no offset, so note the zone from the “Times are in” line when you save the file, or include it in the file name.
7. Fix real gaps. A transaction in the API but not in your ledger means a missed postback, not a time zone issue. Resend the failed postback from Reports, Postbacks.

Frequently asked questions