api-examples

api-examples copied to clipboard

Hi! As we won't be receiving any transactionID anytime soon, it would be great to have a good timestamp for transactions. As it is now, my timestamps comes out like this: 2019-11-08T00:00:00+01:00. If the "T00:00:00" part actually contained when the transactions was made, this would help a lot. Is it possible to add this?

There is more to this issue. It is impossible to be sure what date this accually is without making some kind of assumption.

When using this format on a server that is time zone agnostic, it causes more trouble since the date becomes wrong. A simple parsing and display in ISO format illustrates the issue:

Example in javascript showing the issue:

moment("2019-11-08T00:00:00+01:00").utc().format("YYYY-MM-DD")
// 2019-11-07
moment("2019-11-08T00:00:00+01:00").toISOString()
// 2019-11-07T23:00:00.000Z

Running example here: https://codesandbox.io/s/momentjs-stuff-u17s5

There is more to this issue. It is impossible to be sure what date this accually is without making some kind of assumption.

When using this format on a server that is time zone agnostic, it causes more trouble since the date becomes wrong. A simple parsing and display in ISO format illustrates the issue:

Example in javascript showing the issue:

moment("2019-11-08T00:00:00+01:00").utc().format("YYYY-MM-DD")
// 2019-11-07
moment("2019-11-08T00:00:00+01:00").toISOString()
// 2019-11-07T23:00:00.000Z

Running example here: https://codesandbox.io/s/momentjs-stuff-u17s5

But as the transaction is made, a time-stamp should be recorded locally which is then passed on to the bank. If we could utilize this, the servers timezone is irelevant.

I support @eirikraha proposal of getting more detailed timing information. As I understand from issue #57 there will not be implemented any transaction ID cause of technical reasons. I would guess a reservation is actually simply removed and replaced with a non-reserved transaction at some point when the transactions is settled.

In my scenario I automatically fetch the latest transactions a few times each day and manually "check out" and classify the ones I recognize. I determine uniqueness based on a hash of date, amount and text. Naturally that failes in two scenarios:

1. buying something from the same location with the same cost twice (or more) a day (like a buss ticket)
2. every time the text returned is changed (caused by details being updated when transactions go from reservation to archived. The amount also tends to change caused by currency fluctuations)

Limiting such an import to only source="Archive" and keeping track of dates asked for might be a solution, but still prone to errors, complexity and causes a delay of several days.

Given that the initial accountingDate had a timestamp and it could be guaranteed it did not change, this would actually solve both problems with a very low probability of failing (setting uniqueness based on accountingDate and timestamp only)