Unix timestamp, or even integer based UTC datetimes work perfectly fine.
For serious work, it’s worth noting that leap seconds are not representable in this format. Many financial applications can get away without representing leap seconds, but this is fundamentally a kludge. If you actually need to represent any point in time (according to UTC or any particular timezone), use a representation that actually represents what you want.
This is especially true for future times. If you mean “10 AM, August 1, 2025, New York time”, then represent that! Do not kludge it as an integer, do not use a different time zone as a proxy, do not use UTC, and don’t use a representation that contains the terms “standard” or “daylight”. If you do this wrong, you will eventually regret it. Bonus points for also being able to represent future leap seconds, I suppose, but I’ve never encountered any need to do that.
Keep in mind that those properly represented future times are not guaranteed to ever happen. Time zone definitions can and do change.
Really, this mainly applies to future times. And this guidance is expanded by Simon Willison in this piece which basically recommends:
store the user’s intent time and the location/timezone […] and then denormalize to the UTC time and store that as well.
When storing/manipulating data, ask yourself: what am I trying to represent?
And then represent exactly that.