Are the posted questions getting worse?
- jonathan.crawford wrote: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"
I think the phrase "storing it in UTC only adds to the problem" prompted my reply that's all. Its my understanding that UTC doesn't spring forward or fall back like EST to DST and back for instance, or am I mistaken there too?
- Michael L John wrote: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.
Heh... absolutely not. I have a wonderful body shape that would make the more important lettering at the bottom of the shirt stretch to become much more readable. 😀
--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) -
A heartfelt "thank you" to all you old farts whose wise words of wisdom have kept me from being this story:
Week or two ago a change was implemented to include some of our data in a view into the datalake, and suddenly the entire company could not access the reporting data for this particular data source. Troubleshooting ensued, emergency upgrades of the ETL tools were initiated as recommended by the vendor, to no avail. Then they "fixed" it, but instead of having 11 million records, it had around 800. They worked and worked, but said it took so long to test it was difficult to troubleshoot. Couple days ago they have to rollback changes that were supposed to bring in our data alongside what they already had, so they have a working version but nothing for us.
So, today, we get this notice, actual quote slightly edited to protect the innocent:
"I have a possible fix for the view. Please let me know when you would like me to push these changes so we can test if it is successful. All local query tests on my machine have been successful. "
….I feel sick...
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses - 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?
where do you store the information about the offset AT THAT TIME?
And I have nothing against storing time in UTC. I’m actually strongly in favour. I’m only saying - it’s not enough.
in autumn the hour between 2:00 am and 3:00 am happens twice. If you have no reference to UTC there is no way to tell when a 2:22 am event actually happened. Using datetimeoffset helps with figuring it out, but it does not help when it comes to displaying that time correctly.
if it was 2:22+11:00 then how you display it now, when you’re on +10:00 time offset? An hour later there was another event, recorded on 2:22+10:00. How do you display the time of that event?
they actually both happened at 2:22 local time, so they must be displayed like this.
_____________
Code for TallyGenerator - Jeff Moden wrote:Michael L John wrote: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.
Heh... absolutely not. I have a wonderful body shape that would make the more important lettering at the bottom of the shirt stretch to become much more readable. 😀
True, Jeff, but the shirt in the picture is probably a medium. 😀
On the serious side, that it a really cool shirt.
- Sergiy wrote: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?
where do you store the information about the offset AT THAT TIME?
And I have nothing against storing time in UTC. I’m actually strongly in favour. I’m only saying - it’s not enough.
in autumn the hour between 2:00 am and 3:00 am happens twice. If you have no reference to UTC there is no way to tell when a 2:22 am event actually happened. Using datetimeoffset helps with figuring it out, but it does not help when it comes to displaying that time correctly.
if it was 2:22+11:00 then how you display it now, when you’re on +10:00 time offset? An hour later there was another event, recorded on 2:22+10:00. How do you display the time of that event?
they actually both happened at 2:22 local time, so they must be displayed like this.
I just like to think of it differently that's all. There are three times I deal with, UTC, EST, DST. According to the time of year, I'll either display EST or DST. I don't have to store the offset, I just need to know the schedule of the offset changes, the actual offset really doesn't need stored, it should be treated more as a constant. If it really needs stored, store it as OFFSET_EST = whatever and OFFSET_DST whatever, and of course you'll need access to the schedule to determine which offset to used, based on UTC.
If I'm missing anything let me know!
-
Yep, you're missing one thing.
The thing is - the offset is not a constant.
it was +10:00 yesterday, or an hour ago, but it's +11:00 now.
And your code must reflect that saddening fact correctly.
_____________
Code for TallyGenerator - Sergiy wrote:
Yep, you're missing one thing.
The thing is - the offset is not a constant.
it was +10:00 yesterday, or an hour ago, but it's +11:00 now.
And your code must reflect that saddening fact correctly.
I thought DST's and EST's offsets always stayed the same. Do you have a link that could help me out? The way I thought it worked was that DST or EST were in EFFECT at differently scheduled times of the year, but that their offsets never changed.
Wikipedia:
Places that use Eastern Standard Time (EST) when observing standard time (autumn/winter) are five hours behind Coordinated Universal Time (UTC-05:00).
Eastern Daylight Time (EDT), when observing daylight saving time (spring/summer), is four hours behind Coordinated Universal Time (UTC-04:00).
I was calling it DST lol!
Still, the page doesn't say anything about EST or EDT changing, they're always the same hours behind. The different offset I would see is from switching from EST to EDT or back, but the offsets of those two are constant. In that case, all I would need is the calendar for which offset was in effect according to the calendar and the stored UTC date. If the UTC date falls within the dates that EST is in effect, we use that offset, ditto with EDT.
Would that not work?
-
On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
—Charles Babbage, Passages from the Life of a PhilosopherHow to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
- Neil Burton wrote:
Wow. Just WOW!
--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) -
It's the fact that the spent £12 billion of tax payers money on that spreadsheet that really annoys me. Glad to know my money is going to worth while causes... -_-
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk - Thom A wrote:
It's the fact that the spent £12 billion of tax payers money on that spreadsheet that really annoys me. Glad to know my money is going to worth while causes... -_-
I was seriously considering setting up a consultancy yesterday and offering my services to HM Gov at a fixed fee of £20m to set up a process using punched card, rolled up and attached to carrier pigeons.
"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? - david.edwards 76768 wrote:
I was seriously considering setting up a consultancy yesterday and offering my services to HM Gov at a fixed fee of £20m to set up a process using punched card, rolled up and attached to carrier pigeons.
JC has entered the building.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
- Phil Parkin wrote:david.edwards 76768 wrote:
I was seriously considering setting up a consultancy yesterday and offering my services to HM Gov at a fixed fee of £20m to set up a process using punched card, rolled up and attached to carrier pigeons.
JC has entered the building.
Ahh, so the solution will be written in COBOL.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
Viewing 15 posts - 65,191 through 65,205 (of 66,547 total)
You must be logged in to reply to this topic. Login to reply