Are the posted questions getting worse?
-
Honestly, this is why I personally find it easier to just store anything in UTC if I'm ever working with time sensitive data, or multiple timezones (and I include the having to cope with DST); it simply removes so many layers of ambiguity.
Did MS ever fix the issue where SQL Server Agent doesn't run jobs during the extra hour when the clocks go back? (Still running 2012 at the office, so I know at least the office's instances still suffer it).
Maybe I should change the Office SQL Servers to use UTC too. Heh.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk - Thom A wrote:
Honestly, this is why I personally find it easier to just store anything in UTC if I'm ever working with time sensitive data, or multiple timezones (and I include the having to cope with DST); it simply removes so many layers of ambiguity.
Did MS ever fix the issue where SQL Server Agent doesn't run jobs during the extra hour when the clocks go back? (Still running 2012 at the office, so I know at least the office's instances still suffer it).
Maybe I should change the Office SQL Servers to use UTC too. Heh.
Yep, it would be much better if the whole world just used UK, sorry, UTC time 😀
I was bitten by the Agent problem in my (recent) infancy, I seem to recall the weirdest problem was if the start time was exactly 0200 - I soon got into the habit of making sure anything I needed to run in that window started at 0201. (that was 2008R2 and I have stuck with the habit ever since)
"Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. When we enquire into any subject, the first thing we have to do is to know what books have treated of it. This leads us to look at catalogues, and at the backs of books in libraries."
— Samuel Johnson
I wonder, would the great Samuel Johnson have replaced that with "GIYF" now? - Thom A wrote:
Honestly, this is why I personally find it easier to just store anything in UTC if I'm ever working with time sensitive data, or multiple timezones (and I include the having to cope with DST); it simply removes so many layers of ambiguity.
Did MS ever fix the issue where SQL Server Agent doesn't run jobs during the extra hour when the clocks go back? (Still running 2012 at the office, so I know at least the office's instances still suffer it).
Maybe I should change the Office SQL Servers to use UTC too. Heh.
As we have (and some painfully so) found out through the years is that there is a strong correlation between Time Sensitivity, UTC (or whatever point on chooses) and DST, accurate time reporting is in fact UTC + DST.
😎
Some of the misconceptions have been the timezone that the SQL Server instances are running, it is the database system's responsibility, not the server's instance. As Steve Collins said earlier, the system has to be able to work in the "Now Now"
- Thom A wrote:
Honestly, this is why I personally find it easier to just store anything in UTC if I'm ever working with time sensitive data, or multiple timezones (and I include the having to cope with DST); it simply removes so many layers of ambiguity.
no, it only adds to the problems.
In my example - an order submitted from Sydney on Friday 8:00 am is stored in the database as submitted on Thirsday 10:00 pm. Then DLS changes over weekend, and when you open that order from the same application on Monday you see the time of order submission is either 7:00 or 9:00 am, depending on the direction of the change.
And even datetimeoffset does not help much.
Say, on Friday you recorded 8:00 on +10 hours, and on Monday you're in the time zone with +11 hours. How to tell it's because you've moved to some island in the ocean and 8:00 AEST must be displayed as 9:00 of local time, or it's just DLS time shift and 8:00 must remain 8:00?
_____________
Code for TallyGenerator -
Just found this and, being an older person, I'm loving it.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - Jeff Moden wrote:
Just found this and, being an older person, I'm loving it.
Ha! One of my professors used to have a plaque above his desk "Old age and treachery will always prevail over youth and stamina"
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses - Jeff Moden wrote:
Just found this and, being an older person, I'm loving it.
I can see where this is going;)
😎
- Thom A wrote:Eirikur Eiriksson wrote:Jeff Moden wrote:
Just found this and, being an older person, I'm loving it.
I can see where this is going;)
😎
That appears to be a very young person wearing that though.
True... it's a young person that probably has some personal experience with old people and has "gotten the message". 😀
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - Jeff Moden wrote:Thom A wrote:
That appears to be a very young person wearing that though.
True... it's a young person that probably has some personal experience with old people and has "gotten the message". 😀
I probably can't talk though, they're probably only 10 (and a bit) years younger than me. ??
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk - Thom A wrote:Eirikur Eiriksson wrote:Jeff Moden wrote:
Just found this and, being an older person, I'm loving it.
I can see where this is going;)
😎
That appears to be a very young person wearing that though.
It also appears that this very young person models that shirt much better than Jeff.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/ -
Is this a bad time to point out to you Old People (tm) that most likely that shirt is just PhotoShopped on, and nobody is wearing it?
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses -
Aw cmon Jonathan. Let us at least hold on to our visions of youth.
In between the aches and pains.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/ - Sergiy wrote:Thom A wrote:
Honestly, this is why I personally find it easier to just store anything in UTC if I'm ever working with time sensitive data, or multiple timezones (and I include the having to cope with DST); it simply removes so many layers of ambiguity.
no, it only adds to the problems.
In my example - an order submitted from Sydney on Friday 8:00 am is stored in the database as submitted on Thirsday 10:00 pm. Then DLS changes over weekend, and when you open that order from the same application on Monday you see the time of order submission is either 7:00 or 9:00 am, depending on the direction of the change.
And even datetimeoffset does not help much.
Say, on Friday you recorded 8:00 on +10 hours, and on Monday you're in the time zone with +11 hours. How to tell it's because you've moved to some island in the ocean and 8:00 AEST must be displayed as 9:00 of local time, or it's just DLS time shift and 8:00 must remain 8:00?
I know I would like to understand this better, obviously it might be too much work for everyone else for me to get it LOL
Say, I make an order and its saved in UTC. I make this order before DST. In my thinking, this order's time does not change in either UTC or DST because if I convert from UTC back to my local time zone without taking into consideration what offset was in effect AT THAT TIME, isn't that an error in my coding?
- x wrote:Sergiy wrote:Thom A wrote:
Honestly, this is why I personally find it easier to just store anything in UTC if I'm ever working with time sensitive data, or multiple timezones (and I include the having to cope with DST); it simply removes so many layers of ambiguity.
no, it only adds to the problems.
In my example - an order submitted from Sydney on Friday 8:00 am is stored in the database as submitted on Thirsday 10:00 pm. Then DLS changes over weekend, and when you open that order from the same application on Monday you see the time of order submission is either 7:00 or 9:00 am, depending on the direction of the change.
And even datetimeoffset does not help much.
Say, on Friday you recorded 8:00 on +10 hours, and on Monday you're in the time zone with +11 hours. How to tell it's because you've moved to some island in the ocean and 8:00 AEST must be displayed as 9:00 of local time, or it's just DLS time shift and 8:00 must remain 8:00?
I know I would like to understand this better, obviously it might be too much work for everyone else for me to get it LOL
Say, I make an order and its saved in UTC. I make this order before DST. In my thinking, this order's time does not change in either UTC or DST because if I convert from UTC back to my local time zone without taking into consideration what offset was in effect AT THAT TIME, isn't that an error in my coding?
Yes, but I think the point Sergiy and others are making is that storing values as UTC doesn't obliviate the need for coding that accounts for it somewhere. You could make the same argument that if you store it as current local time, you should have code somewhere that accounts for this when calculating date comparisons across different timezones, etc.
That's why I only ever store datetime values to the nearest Fiscal Year. And before you ask, anything caught in the grey zone is filed under "the cost of doing business"
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
Viewing 15 posts - 65,176 through 65,190 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply