good points, thanks Stuart. will I see you at PASS again this year?

i think we will need to switch to using all UTC timestamps for everything we do. i also believe we should keep the local time of the server, so perhaps just the two columns will suffice. i do hate to store something twice, so maybe just the UTC will be enough.

As noted DST is fun to deal with; try also building a cube for data across time zones when you want to have a dimension by day (what day?UTC? Client local time? server local time?).

I’ve long since advocated that we all abandon the concept of local time, and we each determine our days based on UTC. If I work 12 noon to 8 pm UTC, so be it.

good point, and something to consider as some locations may not observe DST, or if they do, they may not start on the same day.

how come Star Trek never worries about such details when they time travel?

We are quite lucky down here (New Zealand) that we are generally +12 hours from GMT, so our users can easily translate the times if we thorw a (GMT) in the display.

i suppose we could use the GETUTCDATE(), but will that work against SQL2000? If not, then we would need to split out our script to run two versions, one for SQL2000 boxes and the other for servers built in this century.

even with UTC, the OpsMgr agent is still going to run based on the local time. so, 24 servers around the world, and each one would be kicked off, every hour, like…clockwork! the question becomes: what value do you store in the repository? even with UTC, you would still have 24 different values.