getutcdate() issues

[John A Grandy]

Transact-SQL Reference (SQL Server 2000)
GETUTCDATE
Returns the datetime value representing the current UTC time (Universal Time
Coordinate or Greenwich Mean Time). The current UTC time is derived from the
current local time and the time zone setting in the operating system of the
computer on which SQL Server is running.



I find this disconcerting for a few reasons.

1. what if current localtime is wrong ?

2. what if someone has temporarily changed the server's timezone ( perhaps
for debugging reasons ) causing columns with getutcdate() default to be
mis-populated ?

3. how to ensure Windows timezones DST-datetime-ranges are reliably updated
in a timely manner ?

But I suppose the other options cannot be assumed to exist , such as network
assumed and server syncs its utc time against a network timeserver , or inet
access assumed and server syncs against a inet timeserver ...

How is this problem commonly approached in production environments ?

[Aaron Bertrand [SQL Server MVP]]

Post by John A Grandy
1. what if current localtime is wrong ?

Then you'd have the same problem with other information, like GETDATE(),
CURRENT_TIMESTAMP, the SQL Server error log, Agent, etc. etc.

Post by John A Grandy
2. what if someone has temporarily changed the server's timezone ( perhaps
for debugging reasons ) causing columns with getutcdate() default to be
mis-populated ?

Did you try it? GETUTCDATE() is determined exactly by the time zone. If
they change the time zone, GETUTCDATE() is still calculated correctly.

Post by John A Grandy
3. how to ensure Windows timezones DST-datetime-ranges are reliably updated
in a timely manner ?

This is built into Windows. They had an automatic update when George Bush
changed the DST rules a couple of years ago, and it was ready and available
long before it actually changed.

Post by John A Grandy
How is this problem commonly approached in production environments ?

Other than keeping your servers with the correct local time (regardless of
time zone), I'm not sure I understand what "this problem" is.

In our data center, all servers are simply set to UTC, so there are no time
zone conversion issues in storage. And they are all synced by a local time
server. When we need to display time values to end users, we convert to
their time zone preference on the client side.

A

[John A Grandy]

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
1. what if current localtime is wrong ?

Then you'd have the same problem with other information, like GETDATE(),
CURRENT_TIMESTAMP, the SQL Server error log, Agent, etc. etc.

And ... ?

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
2. what if someone has temporarily changed the server's timezone ( perhaps
for debugging reasons ) causing columns with getutcdate() default to be
mis-populated ?

Did you try it? GETUTCDATE() is determined exactly by the time zone. If
they change the time zone, GETUTCDATE() is still calculated correctly.

What if they change timezone but not current datetime accordingly ,
especially w.r.t. DST-crossovers ?

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
3. how to ensure Windows timezones DST-datetime-ranges are reliably updated
in a timely manner ?

This is built into Windows. They had an automatic update when George Bush
changed the DST rules a couple of years ago, and it was ready and available
long before it actually changed.

What if update wasn't applied ?

From what I've heard Windows Timezones are flaky w.r.t. historical DST
start/end ; most data products prefer UNIX timezone database.

It wasn't until .NET 3.5 that you could even convert timezones ( except
local to UTC ; UTC to local )

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
How is this problem commonly approached in production environments ?

Other than keeping your servers with the correct local time (regardless of
time zone), I'm not sure I understand what "this problem" is.
In our data center, all servers are simply set to UTC, so there are no time
zone conversion issues in storage. And they are all synced by a local time
server. When we need to display time values to end users, we convert to
their time zone preference on the client side.

Yeah, that's what we do to.

[Aaron Bertrand [SQL Server MVP]]

Post by John A Grandy

Post by Aaron Bertrand [SQL Server MVP]
Then you'd have the same problem with other information, like GETDATE(),
CURRENT_TIMESTAMP, the SQL Server error log, Agent, etc. etc.

And ... ?

Well, if you don't set the proper local date and time on your Windows
installation, what do you expect SQL Server to do about it for you?

Post by John A Grandy
What if they change timezone but not current datetime accordingly ,
especially w.r.t. DST-crossovers ?

Then as above, the local time will be wrong. Can you paint a specific
scenario where, other than the local time being wrong, this causes a
problem? Can you show an example where changing the timezone (from what
timezone to what timezone) causes a problem with a DST crossover? Shouldn't
only administrators be allowed to change timezones on important servers?

Post by John A Grandy

Post by Aaron Bertrand [SQL Server MVP]
This is built into Windows. They had an automatic update when George Bush
changed the DST rules a couple of years ago, and it was ready and available
long before it actually changed.

What if update wasn't applied ?

I'd be very interested to see any machine that wasn't updated.

Post by John A Grandy
From what I've heard Windows Timezones are flaky w.r.t. historical DST
start/end ; most data products prefer UNIX timezone database.

Do you have any SPECIFIC concerns? What you've "heard" and "flaky" sounds
more like cautious paranoia than a real issue.

[Erland Sommarskog]

Post by Aaron Bertrand [SQL Server MVP]
I'd be very interested to see any machine that wasn't updated.

I've been logged into more than one customer machine with a yellow
shield in the taskbar indicating that there are updates waiting to be
applied.

Apart from that, I have no disagreement on the point that SQL Server
cannot - and should not - try to do better than Windows.

[Aaron Bertrand [SQL Server MVP]]

Post by Erland Sommarskog
I've been logged into more than one customer machine with a yellow
shield in the taskbar indicating that there are updates waiting to be
applied.

Oh I see that all the time too. But an important update from 2007, still
not applied today? That type of administrator is just asking for fallout
problems.

[Erland Sommarskog]

Post by Aaron Bertrand [SQL Server MVP]
Oh I see that all the time too. But an important update from 2007, still
not applied today? That type of administrator is just asking for fallout
problems.

I know have seen more recent time-zone updates to Windows than 2007.

[Aaron Bertrand [SQL Server MVP]]

Post by Erland Sommarskog
I know have seen more recent time-zone updates to Windows than 2007.

Yes there have been minor updates to time zone rules in Morocco, Pakistan,
Baghdad etc. But the major one that had the potential to cause a lot of
grief was the US DST rule change in 2007.

[Erland Sommarskog]

Post by Aaron Bertrand [SQL Server MVP]

Post by Erland Sommarskog
I know have seen more recent time-zone updates to Windows than 2007.

Yes there have been minor updates to time zone rules in Morocco, Pakistan,
Baghdad etc. But the major one that had the potential to cause a lot of
grief was the US DST rule change in 2007.

What do you mean? That in Morrocao, Pakistan and Iraq they don't use
computers, so they won't notice anyway? Or that time-zone changes only
causes grief when the US involved? Or what?

Personally, I don't think I've experienced any computer problems with
time-zone changes in any faraway country, including the US.

[Aaron Bertrand [SQL Server MVP]]

Post by Erland Sommarskog

Post by Aaron Bertrand [SQL Server MVP]
Yes there have been minor updates to time zone rules in Morocco, Pakistan,
Baghdad etc. But the major one that had the potential to cause a lot of
grief was the US DST rule change in 2007.

What do you mean? That in Morrocao, Pakistan and Iraq they don't use
computers, so they won't notice anyway? Or that time-zone changes only
causes grief when the US involved? Or what?

I mean that I do not recall seeing any complaints about DST issues for any
country except for the US changes in 2007. And it is not because I frequent
newsgroups where only US citizens subscribe. IIRC, most of the corrections
in other countries were because there was some problem within the way
Windows was already calculating the offset (e.g. not due to a rule or policy
change). When a rule change is announced, people complain almost
immediately because they calculate some date in the future and the time is
suddenly wrong -- before Microsoft even has a chance to correct the issue.

A

[John A Grandy]

The point I'm making is that the function is named "getutcdate" but is not
guaranteed to return current UTC datetime.

True , those knowledgeable re all the issues are unlikely to misuse the
function , but in real world metrics by which we must judge functionality
include how accessible it is , and how much likelihood there is for
misunderstanding.

I'll bet there are quite a few in-production systems out there with columns
default getutcdate() where improper systems practices have led to all sorts
of bad data.

Also : I don't think that relying on Windows auto-updates ( which many find
annoying and ignore or turn off ) for updating Windows timezones definitions
( including DST start/end ) is a serious enterprise database solution.

Does anyone know how other databases/platforms handle this issue ?

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy

Post by Aaron Bertrand [SQL Server MVP]
Then you'd have the same problem with other information, like GETDATE(),
CURRENT_TIMESTAMP, the SQL Server error log, Agent, etc. etc.

And ... ?

Well, if you don't set the proper local date and time on your Windows
installation, what do you expect SQL Server to do about it for you?

Post by John A Grandy
What if they change timezone but not current datetime accordingly ,
especially w.r.t. DST-crossovers ?

Then as above, the local time will be wrong. Can you paint a specific
scenario where, other than the local time being wrong, this causes a
problem? Can you show an example where changing the timezone (from what
timezone to what timezone) causes a problem with a DST crossover?
Shouldn't
only administrators be allowed to change timezones on important servers?

Post by John A Grandy

Post by Aaron Bertrand [SQL Server MVP]
This is built into Windows. They had an automatic update when George Bush
changed the DST rules a couple of years ago, and it was ready and available
long before it actually changed.

What if update wasn't applied ?

I'd be very interested to see any machine that wasn't updated.

Post by John A Grandy
From what I've heard Windows Timezones are flaky w.r.t. historical DST
start/end ; most data products prefer UNIX timezone database.

Do you have any SPECIFIC concerns? What you've "heard" and "flaky" sounds
more like cautious paranoia than a real issue.

[Aaron Bertrand [SQL Server MVP]]

Post by John A Grandy
The point I'm making is that the function is named "getutcdate" but is not
guaranteed to return current UTC datetime.

Ok, and GETDATE() and CURRENT_TIMESTAMP are supposed are supposed to return
the current local time. If your server has incorrect local time, guess
what? Those will be wrong too. As will the times recorded in the event
log, SQL Server's error log, Agent jobs will be starting at the wrong time,
Windows scheduled tasks will not run when they are expected, and the list
goes on and on... Why the discussion is isolated to GETUTCDATE() I have no
idea. The same problem exists if you are using ASP.NET, or JavaScript, or
WSH, or Perl, or PHP, etc. etc. -- they all use the system clock, and
believe that it is accurate.

Post by John A Grandy
Also : I don't think that relying on Windows auto-updates ( which many find
annoying and ignore or turn off ) for updating Windows timezones definitions
( including DST start/end ) is a serious enterprise database solution.

I still fail to understand why this is the database engine's fault. If your
server has the incorrect time there is plenty going wrong whether or not you
have a database engine installed. Just because Windows updates might be
annoying does not give an inattentive administrator an excuse.

Post by John A Grandy
Does anyone know how other databases/platforms handle this issue ?

Since most do not *require* an Internet connection at all, I have to believe
that they work the same way: they trust the host operating system to provide
them with the correct system clock. I'm sorry John, but I'm afraid you're
pointing fingers in the wrong direction, and if you're expecting Microsoft
to "fix" SQL Server so that it will disobey the local system clock, I don't
think you're going to get very far. But hey, if you think you can make a
coherent enough case for it, you are of course more than welcome to file a
suggestion at connect.microsoft.com/sql ...

[John A Grandy]

Why not give Sql Server its own internal clock ? Runs as part of the
MSSQLSERVER service and syncs 1x/day to a inet timeserver which you must
configure on Sql Server install for certain functions to be available.

Then you could offer a getutcdate() which nearly guaranteed accuracy.

Further , have Sql Server maintain its own timezone database which syncs
1x/day to this same inet timeserver.

The inet timeserver of course is some government maintained "world critical"
system which can be totally relied upon.

I think this is a way better solution that relying on Microsoft Corporation
to provide updates to a flaky Windows Update service which many find
annoying and ignore or turn off.

I'll bet you this is the wave of the future.

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
The point I'm making is that the function is named "getutcdate" but is not
guaranteed to return current UTC datetime.

Ok, and GETDATE() and CURRENT_TIMESTAMP are supposed are supposed to return
the current local time. If your server has incorrect local time, guess
what? Those will be wrong too. As will the times recorded in the event
log, SQL Server's error log, Agent jobs will be starting at the wrong time,
Windows scheduled tasks will not run when they are expected, and the list
goes on and on... Why the discussion is isolated to GETUTCDATE() I have no
idea. The same problem exists if you are using ASP.NET, or JavaScript, or
WSH, or Perl, or PHP, etc. etc. -- they all use the system clock, and
believe that it is accurate.

Post by John A Grandy
Also : I don't think that relying on Windows auto-updates ( which many find
annoying and ignore or turn off ) for updating Windows timezones definitions
( including DST start/end ) is a serious enterprise database solution.

I still fail to understand why this is the database engine's fault. If your
server has the incorrect time there is plenty going wrong whether or not you
have a database engine installed. Just because Windows updates might be
annoying does not give an inattentive administrator an excuse.

Post by John A Grandy
Does anyone know how other databases/platforms handle this issue ?

Since most do not *require* an Internet connection at all, I have to believe
that they work the same way: they trust the host operating system to provide
them with the correct system clock. I'm sorry John, but I'm afraid you're
pointing fingers in the wrong direction, and if you're expecting Microsoft
to "fix" SQL Server so that it will disobey the local system clock, I don't
think you're going to get very far. But hey, if you think you can make a
coherent enough case for it, you are of course more than welcome to file a
suggestion at connect.microsoft.com/sql ...

[John A Grandy]

And come to think of it , I know a couple of good systems engineers who
deliberately turn-off Windows Update on prod machines precisely because they
don't want some ill-advised auto-update hosing their prod system ... and
they don't want "updates are waiting" either because someone may
inadvertently trigger their installation when they are rebooting for some
other reason.

Windows Updates is a TERRIBLE way to maintain a timezone database.

Post by John A Grandy
Why not give Sql Server its own internal clock ? Runs as part of the
MSSQLSERVER service and syncs 1x/day to a inet timeserver which you must
configure on Sql Server install for certain functions to be available.
Then you could offer a getutcdate() which nearly guaranteed accuracy.
Further , have Sql Server maintain its own timezone database which syncs
1x/day to this same inet timeserver.
The inet timeserver of course is some government maintained "world
critical" system which can be totally relied upon.
I think this is a way better solution that relying on Microsoft
Corporation to provide updates to a flaky Windows Update service which
many find annoying and ignore or turn off.
I'll bet you this is the wave of the future.

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
The point I'm making is that the function is named "getutcdate" but is not
guaranteed to return current UTC datetime.

Ok, and GETDATE() and CURRENT_TIMESTAMP are supposed are supposed to return
the current local time. If your server has incorrect local time, guess
what? Those will be wrong too. As will the times recorded in the event
log, SQL Server's error log, Agent jobs will be starting at the wrong time,
Windows scheduled tasks will not run when they are expected, and the list
goes on and on... Why the discussion is isolated to GETUTCDATE() I have no
idea. The same problem exists if you are using ASP.NET, or JavaScript, or
WSH, or Perl, or PHP, etc. etc. -- they all use the system clock, and
believe that it is accurate.

Post by John A Grandy
Also : I don't think that relying on Windows auto-updates ( which many find
annoying and ignore or turn off ) for updating Windows timezones definitions
( including DST start/end ) is a serious enterprise database solution.

I still fail to understand why this is the database engine's fault. If your
server has the incorrect time there is plenty going wrong whether or not you
have a database engine installed. Just because Windows updates might be
annoying does not give an inattentive administrator an excuse.

Post by John A Grandy
Does anyone know how other databases/platforms handle this issue ?

Since most do not *require* an Internet connection at all, I have to believe
that they work the same way: they trust the host operating system to provide
them with the correct system clock. I'm sorry John, but I'm afraid you're
pointing fingers in the wrong direction, and if you're expecting Microsoft
to "fix" SQL Server so that it will disobey the local system clock, I don't
think you're going to get very far. But hey, if you think you can make a
coherent enough case for it, you are of course more than welcome to file a
suggestion at connect.microsoft.com/sql ...

[Aaron Bertrand [SQL Server MVP]]

You can download the updates on your own. If your admin is paying
attention. <shrug>

Post by John A Grandy
And come to think of it , I know a couple of good systems engineers who
deliberately turn-off Windows Update on prod machines precisely because they
don't want some ill-advised auto-update hosing their prod system ... and
they don't want "updates are waiting" either because someone may
inadvertently trigger their installation when they are rebooting for some
other reason.
Windows Updates is a TERRIBLE way to maintain a timezone database.

[Aaron Bertrand [SQL Server MVP]]

Post by John A Grandy
Why not give Sql Server its own internal clock ? Runs as part of the
MSSQLSERVER service and syncs 1x/day to a inet timeserver which you must
configure on Sql Server install for certain functions to be available.

Because not everyone wants their SQL Server instances exposed to the
Internet. And why duplicate the work that Windows already does so well? To
make up for a few lazy admins? Please.

Post by John A Grandy
The inet timeserver of course is some government maintained "world critical"
system which can be totally relied upon.

Do you know anything run by the government that is really as reliable as you
suggest?

Post by John A Grandy
I'll bet you this is the wave of the future.

Ok, good luck...

[John A Grandy]

A few lazy admins ? C'mon.

So , you're saying that right now real world there aren't tons of prod Sql
Server installations with inet access and Windows Update turned on ?

The statistical real world is often different from the carefully planned
ideal.

I don't think it realistic to expect long-term prod installations to have
sysadmins that monitor updates to all timezones' DST start/end dates, and
who download update patches externally and manually apply them to the
server. Do you really think anyone is actually doing this ?

I think Microsoft's reliance on Windows Update to maintain Windows timezones
database is a bust, pure and simple. It's damned if you do , damned if you
don't.

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
Why not give Sql Server its own internal clock ? Runs as part of the
MSSQLSERVER service and syncs 1x/day to a inet timeserver which you must
configure on Sql Server install for certain functions to be available.

Because not everyone wants their SQL Server instances exposed to the
Internet. And why duplicate the work that Windows already does so well?
To
make up for a few lazy admins? Please.

Post by John A Grandy
The inet timeserver of course is some government maintained "world critical"
system which can be totally relied upon.

Do you know anything run by the government that is really as reliable as you
suggest?

Post by John A Grandy
I'll bet you this is the wave of the future.

Ok, good luck...

[Aaron Bertrand [SQL Server MVP]]

Post by John A Grandy
A few lazy admins ? C'mon.

I do consulting and I can tell you right now it is very rare to find a
server whose clock is incorrect, or in the wrong timezone. The update that
came out in 2007 was quite publicized, as was the fact that the change would
affect *many* existing systems. The ones that ignored that (and still
haven't installed it to date!) are the lazy ones I'm talking about. If time
is an important part of your system then you better be sure your admins are
on top of it. This is like saying that it's not up to me to keep my gas
tank full; if I run out of gas, the car manufacturer better have a backup
plan for me!

Post by John A Grandy
I don't think it realistic to expect long-term prod installations to have
sysadmins that monitor updates to all timezones' DST start/end dates, and
who download update patches externally and manually apply them to the
server. Do you really think anyone is actually doing this ?

Well, I can only speak for the realm of systems I have access to, and for
all of them, YES.

Post by John A Grandy
I think Microsoft's reliance on Windows Update to maintain Windows timezones
database is a bust, pure and simple.

Well, since the government changed the rules after the software was
published, I'm not sure what other bright ideas you might have for
retroactively "fixing" Windows?

[John A Grandy]

Uhhh ... I think maintaining modern OS and server applications is a bit more
complex and nuanced than remembering to fill up your tank with gas before it
runs out ... but wait didn't they add idiot lights , buzzers , beeps , and
other indicators ( not to mention reserve tanks ) precisely because lots of
people would otherwise not remember to fill up their tanks in a timely
prudent manner ?

Didn't we have a Y2K crisis because lots of smart certified experienced
professional programmers and sysadmin people were sloppy and short-sighted ?

Post by Aaron Bertrand [SQL Server MVP]

Post by John A Grandy
A few lazy admins ? C'mon.

I do consulting and I can tell you right now it is very rare to find a
server whose clock is incorrect, or in the wrong timezone. The update that
came out in 2007 was quite publicized, as was the fact that the change would
affect *many* existing systems. The ones that ignored that (and still
haven't installed it to date!) are the lazy ones I'm talking about. If time
is an important part of your system then you better be sure your admins are
on top of it. This is like saying that it's not up to me to keep my gas
tank full; if I run out of gas, the car manufacturer better have a backup
plan for me!

Post by John A Grandy
I don't think it realistic to expect long-term prod installations to have
sysadmins that monitor updates to all timezones' DST start/end dates, and
who download update patches externally and manually apply them to the
server. Do you really think anyone is actually doing this ?

Well, I can only speak for the realm of systems I have access to, and for
all of them, YES.

Post by John A Grandy
I think Microsoft's reliance on Windows Update to maintain Windows timezones
database is a bust, pure and simple.

Well, since the government changed the rules after the software was
published, I'm not sure what other bright ideas you might have for
retroactively "fixing" Windows?

[Aaron Bertrand [SQL Server MVP]]

Look John, have fun on your tirade and all, but I strongly recommend filing
a suggestion on Connect instead of trying to pick fights here. Just don't
be too surprised when it gets closed as Won't Fix.

Post by John A Grandy
Uhhh ... I think maintaining modern OS and server applications is a bit more
complex and nuanced than remembering to fill up your tank with gas before it
runs out ... but wait didn't they add idiot lights , buzzers , beeps , and
other indicators ( not to mention reserve tanks ) precisely because lots of
people would otherwise not remember to fill up their tanks in a timely
prudent manner ?
Didn't we have a Y2K crisis because lots of smart certified experienced
professional programmers and sysadmin people were sloppy and short-sighted ?

[John A Grandy]

Nobody is picking fights.

I was attempting to start a reasonable discussion regarding shortcomings of
the existing Sql Server technology. You decided to pre-empt discussion by
unilaterally declaring that there are no problems and the topic is not
worthy of discussion.

This is a serious issue. You seem to be focused on a single recent
DST-change in the US, but that is hardly the extent of the issue, as history
proves that exact definitions of various worldwide timezones can and do
change frequently.

This is especially relevant as more and more databased applications contain
timestamped data of widescale international origin.

Post by Aaron Bertrand [SQL Server MVP]
Look John, have fun on your tirade and all, but I strongly recommend filing
a suggestion on Connect instead of trying to pick fights here. Just don't
be too surprised when it gets closed as Won't Fix.

Post by John A Grandy
Uhhh ... I think maintaining modern OS and server applications is a bit more
complex and nuanced than remembering to fill up your tank with gas before it
runs out ... but wait didn't they add idiot lights , buzzers , beeps , and
other indicators ( not to mention reserve tanks ) precisely because lots of
people would otherwise not remember to fill up their tanks in a timely
prudent manner ?
Didn't we have a Y2K crisis because lots of smart certified experienced
professional programmers and sysadmin people were sloppy and
short-sighted ?

[Steen Schlüter Persson]

Hi,

Like the other ones, I can't really see what your issue is here? Do you want
ot add extra complexity to SQL Server just by adding a function that already
exists in the OS?
To my knowledge ther are several time services available that you can
synchronize your time with so why not just ouse one of them to sync the
clock of the server/OS? Why would it be any better to have a dedicated SQL
Server "time-sync" feature to do this job?

I'm sorry to say, but like the others pointed out I can't really see your
problem. If the time is an important issue for you, I'm sure that you have
set up proper monitoring of the server and this will also include monitoring
the server time and making sure that the server always have the correct
Windows Updates/Patches - no matter if it's applyed automatically or
manually.
--
Regards
Steen Schlüter Persson (DK)

Post by John A Grandy
Nobody is picking fights.
I was attempting to start a reasonable discussion regarding shortcomings
of the existing Sql Server technology. You decided to pre-empt discussion
by unilaterally declaring that there are no problems and the topic is not
worthy of discussion.
This is a serious issue. You seem to be focused on a single recent
DST-change in the US, but that is hardly the extent of the issue, as
history proves that exact definitions of various worldwide timezones can
and do change frequently.
This is especially relevant as more and more databased applications
contain timestamped data of widescale international origin.

Post by Aaron Bertrand [SQL Server MVP]
Look John, have fun on your tirade and all, but I strongly recommend filing
a suggestion on Connect instead of trying to pick fights here. Just don't
be too surprised when it gets closed as Won't Fix.

Post by John A Grandy
Uhhh ... I think maintaining modern OS and server applications is a bit more
complex and nuanced than remembering to fill up your tank with gas before it
runs out ... but wait didn't they add idiot lights , buzzers , beeps , and
other indicators ( not to mention reserve tanks ) precisely because lots of
people would otherwise not remember to fill up their tanks in a timely
prudent manner ?
Didn't we have a Y2K crisis because lots of smart certified experienced
professional programmers and sysadmin people were sloppy and
short-sighted ?

[Aaron Bertrand [SQL Server MVP]]

When did I say there were no problems? I believe what I said was, it is not
SQL Server's problem. Why should SQL Server solve this problem
independently of the operating system? Do you really want SQL Server to get
some update that the operating system doesn't get, and then the two pieces
of software don't agree what the current time or offset is? That sounds
like a mess to me. Again, Microsoft pushes updates for DST/timezone issues.
It is up to your admins to keep your systems up to date, or suffer the
consequences -- which, as I have explained already, are not limited to SQL
Server. If you want a different solution, then please file a Connect item.
I will not argue about it anymore out here.

Post by John A Grandy
Nobody is picking fights.
I was attempting to start a reasonable discussion regarding shortcomings of
the existing Sql Server technology. You decided to pre-empt discussion by
unilaterally declaring that there are no problems and the topic is not
worthy of discussion.
This is a serious issue. You seem to be focused on a single recent
DST-change in the US, but that is hardly the extent of the issue, as history
proves that exact definitions of various worldwide timezones can and do
change frequently.
This is especially relevant as more and more databased applications contain
timestamped data of widescale international origin.

[Erland Sommarskog]

Post by John A Grandy
Why not give Sql Server its own internal clock ? Runs as part of the
MSSQLSERVER service and syncs 1x/day to a inet timeserver which you must
configure on Sql Server install for certain functions to be available.
Then you could offer a getutcdate() which nearly guaranteed accuracy.
Further , have Sql Server maintain its own timezone database which syncs
1x/day to this same inet timeserver.

http://connect.microsoft.com/SqlServer/Feedback

Remeber to make a strong business case for your suggestion. If Microsoft
thinks that sufficiently many customers agree with you, they will of course
implement it.

However, it seems to me whatever is done, it should be in the operating
system and not in SQL Server itself, so that all applications on Windows
can benefit from it.