Not sure how to reason about this library when the underlying Unix timestamp gets modified

[doulighan]

The app relates to NASDAQ market data. All times on the app are only relevant to America/New_York time.

Here's a common use case for me:

Unix timestamp comes in from the server

1. I use utcToZonedTime() to get America/New_York
2. I run timezone-specific comparisons:
   • What market session is the timestamp in? premarket, regular market, etc
   • Does this date fall on a Holiday?
3. Depending on the result, I calculate some new dates:
   • Get me a new date starting at the next Market session (relies on timezone-specific times)
   • Get a new date 4 business days in the future (relies on timezone-specific dates, holidays, and weekends)
4. Take that new date, and send it back to the server in Unix time, to request specific market data

However, I can no longer trust the Unix timestamp of those returned dates. They've been modified.

I can run zonedTimeToUtc(), but as a programmer, I have no good way of knowing whether that date has been modified. I don't know if another function called utcToZonedTime(), or if its an original local datetime. Theres no flags or properties on the object to signify that, hey, the actual unix timestamp has been tampered with, you can't trust me.

Combine this with the other use case where users are generating local datetimes via Inputs, and it ends up creating this mess of code where some functions rely on local datetimes, and some rely on modified ones, and some both at the same time. Programmers just have to hope they remember to use the correct one. Functions are no longer composable because of this. If you run zonedTimeToUtc or utcToZonedTime twice by accident you've got completely invalid results.

Is there some strategy people have been using? Am I reasoning about this wrong? At this point I can only think to create a wrapper class around Date() that signifies its status as an "untrustworthy" America/New_York one, and allows me to actually type-check arguments properly.