Thomas Baekdal

I had the weirdest problem. In my accounting system, my importer from Stripe kept failing on a single transaction, dated "2025-03-30 02:02:53" ... It looks fine, right?

Well, what if I tell you that this time doesn't exist in Denmark?

The problem here is that Stripe, being a US company, has a different daylight saving time than Denmark.

In the US DST was on 9 March 2025, while in Denmark it was on 30 March 2025, so while the date is correct in the USA, it doesn't exist in Denmark.

Mar 20 at 10:37amWeb
Show threadChristopher IseneMar 20

@baekdal Meh ... such systems should be UTC only, zero offset and zero DST.

DST makes no sense. Never did.

Show thread🇪🇺 Paul Schoonhoven 🍋🍉Mar 20
@cisene @baekdal
IT doesn't matter how a system works. These errors should not occur in financial services.
Show threadChristopher IseneMar 20

@vosje62 @baekdal .. and why would any system import a timestamp from a foreign system, as a DateTime is also a question.

Maybe just a log entry as a string ..

Show threadTroed SångbergMar 20

@vosje62

Without going into details I had to teach a fintech company's existing developers about "never use floats for money" not too long ago ...

@cisene @baekdal

Show threadChristopher IseneMar 20
@troed @vosje62 @baekdal Heh... had a similar problem way back, ERP sent floats and SAP misinterpreted them, as they also had different locales active, where dot/period and commas were used, solution redeclare field as integers .. fractions were multiplied away, and then tell both ends to revise their schemas.