3 ms·

One more: Timezones Various platforms use: UTC, the user’s timezone as set in their dashboard, the user’s detected timezone, the timezone of the server that is

One more: Timezones Various platforms use: UTC, the user’s timezone as set in their dashboard, the user’s detected timezone, the timezone of the server that is generating the reports. Aggregating or reconciling data from different platforms can be a pain if the timezones aren’t clearly indicated. I’ve had bank statements that didn’t agree to CSV exports of the same data because the servers generating the two reports were in different timezones.

SilasX 3y ago
Haha yeah for the past tax year I I looked at my transaction history and it was missing some that I expected to be there. Turns out, the exchange (Gemini, for crypto) uses UTC, but the IRS docs always tell you that a cutoff is relative to your own time zone. The transactions were in the late evening on New Year's Eve, central US time, but that was already the next year by UTC, so any readout of "transactions for 2022" would not include them. [1] e.g. https://www.irs.gov/taxtopics/tc301 https://www.irs.gov/taxtopics/tc301
- koolba 3y ago
  That’d be a great subplot for a movie. The antagonist sets up an elaborate money laundering operation that leverages conflicting definitions of the taxable year and moves off shore profits that are “lost” between the systems. Could call it “Black Ink to the Future.
- radiator 3y ago
  That is supposed to be a festive hour, not one for trading.
  - SilasX 3y ago
    Haha, you're not wrong. I think it was actually more like 8pm, shortly before I left to live it up. But either way, transacting near the new year shouldn't break financial systems.
SideburnsOfDoom 3y ago
That's why Datetime data should be handled in a type that includes this data (e.g. DateTimeOffset (1) ) and exchanged as ISO 8601 with offset. e.g. "2023‐06‐28T15:55:22+01:00" 1) https://learn.microsoft.com/en-us/dotnet/api/system.datetimeoffset https://learn.microsoft.com/en-us/dotnet/api/system.datetime...
theptip 3y ago
Furthermore, even for “date fields”, consider using a datetime. Every date implicitly exists in a timezone, and if you ignore that ambiguity you’ll get bitten later. For example, an invoice due on Friday is probably actually due by close of business (5pm say) in the timezone your business operates, and if created at 11pm it would be processed the next day (or even on Monday, don’t get me started about business day calculations).
- bostik 3y ago
  > Every date implicitly exists in a timezone, and if you ignore that ambiguity you’ll get bitten later. Solid advice, and must come from painful burns. I've been preaching from the same book for a few years now: a timestamp without timezone offset is worse than useless. Or as the DB expert in previous job so eloquently put it... Timestamp with zone tells you when an event actually happened. A timestamp without zone or offset is equal to wall clock time inside a windowless room, which itself is in an unspecified location somewhere on the planet.
lightbendover 3y ago
We stored and transmitted exclusively UTC, which put the burden on the UI at display time (trivial) and backend business logic (complex, but simplified with robust utility functions that everyone understood well) in accounting for timezones when material. We only had a dozen issues due to it so I believe it worked pretty well compared to the war stories I heard from comparable companies in the fintech space.

SilasX 3y ago

Haha yeah for the past tax year I I looked at my transaction history and it was missing some that I expected to be there. Turns out, the exchange (Gemini, for crypto) uses UTC, but the IRS docs always tell you that a cutoff is relative to your own time zone. The transactions were in the late evening on New Year's Eve, central US time, but that was already the next year by UTC, so any readout of "transactions for 2022" would not include them. [1] e.g. https://www.irs.gov/taxtopics/tc301 https://www.irs.gov/taxtopics/tc301

koolba 3y ago
That’d be a great subplot for a movie. The antagonist sets up an elaborate money laundering operation that leverages conflicting definitions of the taxable year and moves off shore profits that are “lost” between the systems. Could call it “Black Ink to the Future.
radiator 3y ago
That is supposed to be a festive hour, not one for trading.
- SilasX 3y ago
  Haha, you're not wrong. I think it was actually more like 8pm, shortly before I left to live it up. But either way, transacting near the new year shouldn't break financial systems.

SideburnsOfDoom 3y ago

That's why Datetime data should be handled in a type that includes this data (e.g. DateTimeOffset (1) ) and exchanged as ISO 8601 with offset. e.g. "2023‐06‐28T15:55:22+01:00" 1) https://learn.microsoft.com/en-us/dotnet/api/system.datetimeoffset https://learn.microsoft.com/en-us/dotnet/api/system.datetime...

theptip 3y ago

Furthermore, even for “date fields”, consider using a datetime. Every date implicitly exists in a timezone, and if you ignore that ambiguity you’ll get bitten later. For example, an invoice due on Friday is probably actually due by close of business (5pm say) in the timezone your business operates, and if created at 11pm it would be processed the next day (or even on Monday, don’t get me started about business day calculations).

bostik 3y ago
> Every date implicitly exists in a timezone, and if you ignore that ambiguity you’ll get bitten later. Solid advice, and must come from painful burns. I've been preaching from the same book for a few years now: a timestamp without timezone offset is worse than useless. Or as the DB expert in previous job so eloquently put it... Timestamp with zone tells you when an event actually happened. A timestamp without zone or offset is equal to wall clock time inside a windowless room, which itself is in an unspecified location somewhere on the planet.

lightbendover 3y ago

We stored and transmitted exclusively UTC, which put the burden on the UI at display time (trivial) and backend business logic (complex, but simplified with robust utility functions that everyone understood well) in accounting for timezones when material. We only had a dozen issues due to it so I believe it worked pretty well compared to the war stories I heard from comparable companies in the fintech space.