Does your data take "leap seconds" and things like that into account? There have been several over the last 42 years. They don't matter to very many people, but if you're measuring events with millisecond precision, it may matter.

Also, you'll need to take into account that the "Spring Ahead" day is an hour shorter, per the clock, than every other day of the year, while the "Fall Back" day is an hour longer. (Yes, we have 1 day per year that's 23 hours long and another that's 25 hours long. Only politicians could inflict that kind of insanity on the world.)

Plus, the schedule of the start and end of DST has changed a few times, so which day is shorter and which one is longer, depends on the year you're asking about.

To accommodate all that kind of confusion, I think a Calendar table is really your best bet. A table with all the dates you need, including something like a century of future dates, with a DayStart and DayEnd value in each, which contains the start and end millisecond values for each date. It's going to be a little bit of a pain to build, but, once built, you won't have to worry about the math on it. Just join to that table using Between on those two columns, and you've got your date range.