My first question would be why do you want to include DST? For KPI reporting purposes (e.g. number of tickets opened / closed this month) it’s not going to seriously affect the precision of a KPI if for some months of the year the month starts and ends an hour early.
But if you really, really need to do this, you will need to set up a reference table of DST starts and ends and then write an SQL function that you can use to return the DST offset (0 or 1) for any given date. Then you can use the offset in formulas like “dateadd(second, SDMdate + offset6060, ’01-01-1970 08:00:00’)” – the ’01-01-1970 08:00:00’ reflects my time zone’s offset from UTC – yours will be different. Be prepared to maintain your reference table over the coming years. There is (at least according to my limited research on the subject) no switch you can turn on in SQL to do it. Thankfully I live in a state that only ever tried DST for one year, and then voted not to bother with it!
Regards,
James