SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Abolish Disjointed Time

By Steve Jones,

One of the more complex types of data to deal with is date data. We have dates, times, strange rules for when mathematical operations occur, and when they don't. We have a period, which can be some combination of these, and that can include math rules that must be programmed consistently. Add to the issue of time zones where 3:00 isn't 3:00 everywhere in the world, especially those strange half and quarter time offset zones, and it's much more complex than seems necessary. There are no shortage of questions and articles at SQLServerCentral because this is a complex topic.

I read recently that the European Parliment is considering getting rid of DST. Quite a few of the members think the practice isn't useful and in a 384 to 153 vote, they decided to review whether or not they think this is a practice that should continue. There have been studies that show the change doesn't help with power, and it's certainly disruptive to everyone. I know it seems a percentage of people are always confused and either arrive early or late every year (or twice a year) when the clocks change. I know I've been late to work in the past on a Sunday when the clocks changed. 

I'm of the opinion that we shoudl do away with DST. I get a double whammy every year the I work for a company in the UK and the US changes clocks at a different time. That means I get meetings that move for a few weeks, and just as I adjust to the new time, they move back. It's a pain, and I'd just as soon do without it. There are also the adjustments to body clocks that likely slow our work and study habits, or at least mine, for a period of time. I'd just prefer that we stick to a single time schedule the entire year.

From a data perspective, the adjustments can cause issues with reporting and tracking data. Having an hour essentially repeat itself can distort any aggregation over that time period. Likewise losing an hour, especially if we use left joins to ensure each time period has a value, can look funny. I know the data issues aren't likely a big deal, after all, how much data does your company gather in the middle of Saturday night a couple times a year? Most reports probably don't bother to account for the discrepencies, and there don't seem to have been any issues I've seen from organizations. It's annoying to me as a data person, but it's probably not a significant issue.

Ultimately I think DST is just a little silly in this modern world, where specific times, especially daylight time, seems to be less of an issue. I work when I need to, take time off when I can, and it seems more and more companies do the same thing. Whether I go to work in the light or dark, the days are shorter in the winter.

Total article views: 61 | Views in the last 30 days: 1
Related Articles

CPU Spikes Caused by Periodic Scheduled Jobs

This article shows how to reduce the periodic spikes in the CPU that are caused by the periodic-exec...


Adjusting Model

This Friday Steve Jones looks at the topic of defaults and whether you use the model database to adj...


Split a date-range into periods

one period can not overlap multiple months


Back in the USSRS

After a period of abstinence, Rodney Landrum adjusts to life back in the USSRS.


Lock request time our period exceeded

Lock request time our period exceeded

database weekly