Problem with transactions between 0:00 and 2:00

[metabubble]

Hi,

is there a potential problem with timezones? I have noticed, that transactions that happen right after midnight, they show up

• in the app with the correct local date
• in the API (which I use with MoneyMoney) with date -1
• not at all in ynab

2023-08-08T00:57:19.958+02:00 | 2023-08-07 22:57:19,958 \| INFO \| sync.py:158 \| synchronize_account \| Synching "Christian Hawkins" - "Girokonto" to "Family Budget" - "bunq Girokonto"...
-- | --
  | 2023-08-08T00:57:19.958+02:00 | 2023-08-07 22:57:19,958 \| INFO \| sync.py:167 \| synchronize_account \| Reading ynab transactions from 2023-07-03...
  | 2023-08-08T00:57:20.497+02:00 | 2023-08-07 22:57:20,497 \| INFO \| sync.py:170 \| synchronize_account \| Retrieved 151 ynab transactions...
  | 2023-08-08T00:57:20.497+02:00 | 2023-08-07 22:57:20,497 \| INFO \| sync.py:176 \| synchronize_account \| Reading bunq payments from 2023-08-08...
  | 2023-08-08T00:57:22.041+02:00 | 2023-08-07 22:57:22,041 \| INFO \| bunq_api.py:151 \| get_payments \| Retrieved back to 2023-04-01...
  | 2023-08-08T00:57:22.041+02:00 | 2023-08-07 22:57:22,041 \| INFO \| sync.py:179 \| synchronize_account \| Retrieved 0 bunq payments...
  | 2023-08-08T00:57:22.042+02:00 | 2023-08-07 22:57:22,042 \| INFO \| sync.py:191 \| synchronize_account \| "Christian Hawkins" - "Girokonto" to "Family Budget" - "bunq Girokonto": Created 0 and patched 0 transactions.
  | 2023-08-08T00:57:22.042+02:00 | 2023-08-07 22:57:22,042 \| INFO \| lambda_function.py:13 \| add_callbacks \| SSM callback = "https://xxxxxxxxxxxxxx.execute-api.eu-central-1.amazonaws.com/bunq2ynab-lambda"
  | 2023-08-08T00:57:22.042+02:00 | 2023-08-07 22:57:22,042 \| INFO \| lambda_function.py:16 \| add_callbacks \| Adding callbacks...

So what I can see here after midnight is, that it is reading transactions from "today", but the api exposes these transactions with yesterday's date, at least according to moneymoney.

P.S: I am running on AWS as lambda function

[wesselt]

Thanks for your report! Bunq2ynab uses the "created" date from the API:

      "Payment": {
        "id": xxx,
        "created": "2020-07-22 13:11:00.693934",
        "updated": "2020-07-22 13:11:00.693934",
        "monetary_account_id": xxx,
        "amount": {
          "currency": "EUR",
          "value": "0.95"
        },

It only looks at the date part ("2020-07-22" in the example.) I assumed both the Bunq and YNAB API use UTC.

I'm surprised it doesn't show up in YNAB at all. Perhaps we can find a hint in the logging. What do you see when you run the script with the "-v" parameter? The output might be large.

[metabubble]

I can run it with the -v parameter manually next time I am up past midnight to test. However, I think we are already on it:

| 2023-08-08T00:57:20.497+02:00 | 2023-08-07 22:57:20,497 | INFO | sync.py:176 | synchronize_account | Reading bunq payments from 2023-08-08...

at localtime 2023-08-08T00:57:20.497+02:00, which is UTC 2023-08-07 22:57:20,497 the script was reading transactions from 2023-08-08

Let me know if testing is still necessary or if that is the hint we need.

[wesselt]

Looks like both APIs use ISO 8601 and UTC: https://api.ynab.com/#best-practices https://beta.doc.bunq.com/basics/api-conventions#time-formats

[wesselt]

Interesting. Bunq2ynab uses the date of the last transaction from YNAB as the first date to read from BUNQ. So I wonder what transactions the YNAB API returns to make the script use an UTC date in the future.

What's your last YNAB transaction? Do you use their scheduled transaction feature?

[metabubble]

Yes, that's it. I scheduled a transaction for today in YNAB, and it was executed at around 1am.

[wesselt]

Did some testing, it's not easy to reproduce. A scheduled transaction remains uncleared until it's matched, and when bunq2ynab calculates the start date, it ignores uncleared transactions. Do you remember any manual actions, like marking the transaction as cleared?

[metabubble]

Yes, I did. It was doing multiple card top ups from different cards after midnight and the first one worked, the subsequent ones didn't.

The reason why I recorded the transactions first was, because they were transfers and not transactions. I guess that is an ultra edgecase that might even be just irgnored. Most bunqers should be where this is only a problem in a 2 hour window when more than one transactions occur in that window and they are cleared manually

On the other hand, deducting the timezone offset from the current datetime to adjust the date by one day (if needed) for reading bunq transactions might be a universal fix, that can catch other timezone related issues.

[wesselt]

Ah that clears it up. This can probably be fixed by ensuring the start date is not in the future. I'll try to write that in.

[wesselt]

Should be resolved by https://github.com/wesselt/bunq2ynab/commit/96e1d41e469623f85d12ba8462270cd808046caf