Congress is debating an Energy bill, and one of the measures of that bill is to lengthen Daylight Savings Time about a month.
For those who may be outside of the US, or places along the equator, there are some countries that change their time clocks to take advantage of more sunlight during the local summer months. In the United States, we change our clocks at the first Sunday in April, and again at the last Sunday in October. In April, we move our clocks ahead one hour (Spring Ahead), and in October, we move them back (Fall Back). By doing this, we add more hours of daylight to be more active, and during our colder winter months, it encourages more inside / sleep time.
With Congress considering these bills, think of the following:
* How do computers handle the time change? When decisions of what files are older/newer for backups and databases, how is that handled? Do the programs consult the "system time", or do they go with a hard-coded routine?
* How will other programs outside your enterprise be affected by the time change?
* How about hard-coded devices, like your VCR, that knows how to change the time today, but will not know the new standard enforced by Congress?
Considering that most programs have been written since the 1970's, they have lived in an era of a standardized time scheme. Now, with some ink from Congress, think of all the IT processes that need to be considered and executed.
I forsee a situation similar to the great Y2K situation: a complete audit of industry code to see how the timechange is handled, so that software vendors can see if they rely on the system to change the time, or go with their own internal code.
Personally, I like the idea. Not because it is more work, but because I like being active, and felt that October was too early to have the Sun go down so early.
Christian