It's about TIME for a programming question
-
The problem with time is that it is (of course) different depending on your time zone and daylight savings time for your region. Scenario 1: Let's say I make a blog entry at 8 AM EST, then I get on an airplane and fly to CA and set my computer to PST. When I look at my blog entry, it probably says that I made the post at 5 AM, but in my thinking, my frame of reference is still "when did I make that post (when I was in NY)?" Scenario 2: I make a blog entry at 8 AM EST, and you, living in CA, notice my blog entry, which has a time of 5 AM (because you're in PST.) That makes sense to you, in your reference frame, because you know you're 3 hours earlier. Scenario 3: I run a company that has ATM's (disclaimer: this is a good example, irrelevant to the fact that write software for ATM's, I'm not asking you to solve programming problem in that regard) in local gas stations all over the country. A customer in NY (UTC-5 at some points of the year) calls and says the ATM didn't dispense cash or a receipt! The help desk asks when they did the transaction, and they say, around 8 AM because that's the time in NY. The customer service is in CA (UTC-8 at the moment, we'll customer service in India for this scenario), so what time do they search for? Do they need to ask "where were you?" so they know the time zone and mentally subtract off 3 hours (maybe dealing a 1 AM NY transaction on 1/1/2016 now being seen in CA as 12/31/2015 10 PM????) So the question becomes, what does the user need to see, and what do they expect to see? When (harhar) does it make more sense to store date/time in the true local time, including timezone (either "PST" style notation, or "UTC-8" notation, for example, keeping in mind that not everyone knows what "UTC" is or even timezone designations like EST, MST, PST, etc. When does it make sense to convert to local time? Should both "my local time" and "transaction local time" be available for displaying/searching? Am I missing something obvious? Have you had to deal with this issue? And I haven't even touched the nightmare of daylight savings time. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventual
I think dealing with time in code is one of the hardest things I've worked on, and I still don't know what the best solution is. I've done it a lot over the years. To avoid daylight saving issues, I tend to store everything in UTC (or GMT to give it its correct title!), then do local conversion. If everything feeds in UTC then at least the same DateTime refers to the same moment wherever you are. But if you have any scheduled tasks, these will need to be rescheduled twice a year as you enter and exit daylight saving. The main problem is that other people don't (use UTC), DateTime.Now is too easy, and this humble type's 'kind' only tells you whether it is UTC/local etc, but not where local is. By the time its gone in and out of SQL server it might have been the time on the moon for all its worth. Then there's UTC to local time and back conversion which is not that easy. Hmmmmm, I don't know where I'm going with this - not a clue. Horrible. But good luck..!
Regards, Rob Philpott.
-
The problem with time is that it is (of course) different depending on your time zone and daylight savings time for your region. Scenario 1: Let's say I make a blog entry at 8 AM EST, then I get on an airplane and fly to CA and set my computer to PST. When I look at my blog entry, it probably says that I made the post at 5 AM, but in my thinking, my frame of reference is still "when did I make that post (when I was in NY)?" Scenario 2: I make a blog entry at 8 AM EST, and you, living in CA, notice my blog entry, which has a time of 5 AM (because you're in PST.) That makes sense to you, in your reference frame, because you know you're 3 hours earlier. Scenario 3: I run a company that has ATM's (disclaimer: this is a good example, irrelevant to the fact that write software for ATM's, I'm not asking you to solve programming problem in that regard) in local gas stations all over the country. A customer in NY (UTC-5 at some points of the year) calls and says the ATM didn't dispense cash or a receipt! The help desk asks when they did the transaction, and they say, around 8 AM because that's the time in NY. The customer service is in CA (UTC-8 at the moment, we'll customer service in India for this scenario), so what time do they search for? Do they need to ask "where were you?" so they know the time zone and mentally subtract off 3 hours (maybe dealing a 1 AM NY transaction on 1/1/2016 now being seen in CA as 12/31/2015 10 PM????) So the question becomes, what does the user need to see, and what do they expect to see? When (harhar) does it make more sense to store date/time in the true local time, including timezone (either "PST" style notation, or "UTC-8" notation, for example, keeping in mind that not everyone knows what "UTC" is or even timezone designations like EST, MST, PST, etc. When does it make sense to convert to local time? Should both "my local time" and "transaction local time" be available for displaying/searching? Am I missing something obvious? Have you had to deal with this issue? And I haven't even touched the nightmare of daylight savings time. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventual
Finishing my contract with Clarity Medical Systems and had an interview for 4:00 PM. The person I was interviewing with was in MST while I am in PST. Well the person scheduling the Interview converted for me, but unfortunately the that was giving the interview converted again, and so did not get a call until 5:00 PM. In China they only have one time zone. Somebody has recommended going to two in the US. Think this is a good idea. The Eastern Time Zone has been pushed so far West that it is practically to the Mississippi. Why not just take it all the way to the Mississippi, and maybe a little further. The Central Time Zone is huge despite encroachment by the Eastern Time zone, and the Pacific Time Zone covers all of Nevada to the border of Alaska. Two time zones sounds better than the 4 we have.
-
HobbyProggy wrote:
That was "unbelievable tortoise crash" right?
When the tortoise[^] crashes, the world comes to an end. :~ Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
In my business we never store local time - conversion to/from that is always a UI or interface concern.
Duncan Edwards Jones wrote:
In my business we never store local time - conversion to/from that is always a UI or interface concern.
Yes, storing the UTC time is definitely the starting point, and I agree, the conversion to/from is a UI concern, but for it to do it's job correctly for the requirements, it may need additional information, at least, that's my thinking. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
The problem with time is that it is (of course) different depending on your time zone and daylight savings time for your region. Scenario 1: Let's say I make a blog entry at 8 AM EST, then I get on an airplane and fly to CA and set my computer to PST. When I look at my blog entry, it probably says that I made the post at 5 AM, but in my thinking, my frame of reference is still "when did I make that post (when I was in NY)?" Scenario 2: I make a blog entry at 8 AM EST, and you, living in CA, notice my blog entry, which has a time of 5 AM (because you're in PST.) That makes sense to you, in your reference frame, because you know you're 3 hours earlier. Scenario 3: I run a company that has ATM's (disclaimer: this is a good example, irrelevant to the fact that write software for ATM's, I'm not asking you to solve programming problem in that regard) in local gas stations all over the country. A customer in NY (UTC-5 at some points of the year) calls and says the ATM didn't dispense cash or a receipt! The help desk asks when they did the transaction, and they say, around 8 AM because that's the time in NY. The customer service is in CA (UTC-8 at the moment, we'll customer service in India for this scenario), so what time do they search for? Do they need to ask "where were you?" so they know the time zone and mentally subtract off 3 hours (maybe dealing a 1 AM NY transaction on 1/1/2016 now being seen in CA as 12/31/2015 10 PM????) So the question becomes, what does the user need to see, and what do they expect to see? When (harhar) does it make more sense to store date/time in the true local time, including timezone (either "PST" style notation, or "UTC-8" notation, for example, keeping in mind that not everyone knows what "UTC" is or even timezone designations like EST, MST, PST, etc. When does it make sense to convert to local time? Should both "my local time" and "transaction local time" be available for displaying/searching? Am I missing something obvious? Have you had to deal with this issue? And I haven't even touched the nightmare of daylight savings time. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventual
In my experience when you call up to say the ATM didn't dispense cash, they'll ask you which ATM. So just use the local time of the ATM.
-
Time is an illusion. Lunch time doubly so. However, you always store your times in UTC. Convert to local time for the observer, on-the-fly. If I am reading this in CA, then show that time zone (with the -PST). If I am in Washington, show -EST or -EDT).... Or did I misunderstand the question?
Basildane wrote:
However, you always store your times in UTC. Convert to local time for the observer, on-the-fly.
Yup.
Basildane wrote:
Or did I misunderstand the question?
Except the time displayed may need to be relative to where/when the transaction took place, rather than where the viewer is. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
Just forget about Earth time and use galactic time. :-\
if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
Foothill wrote:
Just forget about Earth time and use galactic time.
That is awesome. I may actually let the user select that as an optional display format! :jig: Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
Marc Clifton wrote:
Have you had to deal with this issue?
Yes, and it drove me to distraction since no one seemed to understand the problem. Rather than storing the time as local we were saving it as UTC but with an added field that was the offset to local. It never worked satisfactorily, and the project got canned.
Richard MacCutchan wrote:
It never worked satisfactorily, and the project got canned.
:doh: Seems like a problem looking for a solution. Hmmmm... Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
My last 'new' project was/is a cloud based timeclock. I'm probably doing it all wrong, but found it easier to store converted local times and straight utc times for everything. Of course, it all depends on the type of application and whether or not you have users in multiple time zones.
"Go forth into the source" - Neal Morse
kmoorevs wrote:
but found it easier to store converted local times and straight utc times for everything.
Agreed, that should be the baseline (or is that "basetime"?)
kmoorevs wrote:
Of course, it all depends on the type of application and whether or not you have users in multiple time zones.
Web app, possibly desktop app, but I'm poking at what hopefully can be a general solution "library" / best practices. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
I think dealing with time in code is one of the hardest things I've worked on, and I still don't know what the best solution is. I've done it a lot over the years. To avoid daylight saving issues, I tend to store everything in UTC (or GMT to give it its correct title!), then do local conversion. If everything feeds in UTC then at least the same DateTime refers to the same moment wherever you are. But if you have any scheduled tasks, these will need to be rescheduled twice a year as you enter and exit daylight saving. The main problem is that other people don't (use UTC), DateTime.Now is too easy, and this humble type's 'kind' only tells you whether it is UTC/local etc, but not where local is. By the time its gone in and out of SQL server it might have been the time on the moon for all its worth. Then there's UTC to local time and back conversion which is not that easy. Hmmmmm, I don't know where I'm going with this - not a clue. Horrible. But good luck..!
Regards, Rob Philpott.
Rob Philpott wrote:
But good luck..!
Thanks! :) > But if you have any scheduled tasks, these will need to be rescheduled twice a year as you enter and exit daylight saving. Ugh. Another interesting wrinkle in the fabric of time. Hah! Just came up with the name for a potential article: "A Wrinkle in Time" :) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
Finishing my contract with Clarity Medical Systems and had an interview for 4:00 PM. The person I was interviewing with was in MST while I am in PST. Well the person scheduling the Interview converted for me, but unfortunately the that was giving the interview converted again, and so did not get a call until 5:00 PM. In China they only have one time zone. Somebody has recommended going to two in the US. Think this is a good idea. The Eastern Time Zone has been pushed so far West that it is practically to the Mississippi. Why not just take it all the way to the Mississippi, and maybe a little further. The Central Time Zone is huge despite encroachment by the Eastern Time zone, and the Pacific Time Zone covers all of Nevada to the border of Alaska. Two time zones sounds better than the 4 we have.
Clifford Nelson wrote:
Two time zones sounds better than the 4 we have.
And the weird holes, particularly states and very local regions that ignore DST. :doh: Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
In my experience when you call up to say the ATM didn't dispense cash, they'll ask you which ATM. So just use the local time of the ATM.
WiganLatics wrote:
they'll ask you which ATM.
Quite true. But that's assuming the user wasn't drunk, is still by the ATM, and remembers which one they visited. ;) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
Clifford Nelson wrote:
Two time zones sounds better than the 4 we have.
And the weird holes, particularly states and very local regions that ignore DST. :doh: Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Think the only state that ignores DST, which I think should be eliminated is Arizona. Have lived there. Sort preferred being on Pacific time rather than Mountain time. Then there are all those strange incursions, like Idaho into Oregon and Washington into Idaho.
-
Duncan Edwards Jones wrote:
In my business we never store local time - conversion to/from that is always a UI or interface concern.
Yes, storing the UTC time is definitely the starting point, and I agree, the conversion to/from is a UI concern, but for it to do it's job correctly for the requirements, it may need additional information, at least, that's my thinking. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
That is definitely needed, yes. Most operating systems and browsers support "locale" information to allow the user interface to discover its location. For phone apps there is the Google maps Timezone API[^] and worst case scenario you can get the client to specify the timezone. If you need to store where the time came from then you could have a "client offset" field that tells you what time the client thought it was when they wrote the record.
-
I, once, worked on this project - Noda Time | Date and time API for .NET[^] (no warranty and/or guaranty ;) )
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Wow, I just read through the Trivia page. Geez, what a crazy world. I can't imagine the complexity historians have to deal with. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
The problem with time is that it is (of course) different depending on your time zone and daylight savings time for your region. Scenario 1: Let's say I make a blog entry at 8 AM EST, then I get on an airplane and fly to CA and set my computer to PST. When I look at my blog entry, it probably says that I made the post at 5 AM, but in my thinking, my frame of reference is still "when did I make that post (when I was in NY)?" Scenario 2: I make a blog entry at 8 AM EST, and you, living in CA, notice my blog entry, which has a time of 5 AM (because you're in PST.) That makes sense to you, in your reference frame, because you know you're 3 hours earlier. Scenario 3: I run a company that has ATM's (disclaimer: this is a good example, irrelevant to the fact that write software for ATM's, I'm not asking you to solve programming problem in that regard) in local gas stations all over the country. A customer in NY (UTC-5 at some points of the year) calls and says the ATM didn't dispense cash or a receipt! The help desk asks when they did the transaction, and they say, around 8 AM because that's the time in NY. The customer service is in CA (UTC-8 at the moment, we'll customer service in India for this scenario), so what time do they search for? Do they need to ask "where were you?" so they know the time zone and mentally subtract off 3 hours (maybe dealing a 1 AM NY transaction on 1/1/2016 now being seen in CA as 12/31/2015 10 PM????) So the question becomes, what does the user need to see, and what do they expect to see? When (harhar) does it make more sense to store date/time in the true local time, including timezone (either "PST" style notation, or "UTC-8" notation, for example, keeping in mind that not everyone knows what "UTC" is or even timezone designations like EST, MST, PST, etc. When does it make sense to convert to local time? Should both "my local time" and "transaction local time" be available for displaying/searching? Am I missing something obvious? Have you had to deal with this issue? And I haven't even touched the nightmare of daylight savings time. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventual
Marc Clifton wrote:
Am I missing something obvious? Have you had to deal with this issue?
Yes. You store the time in UTC and then apply any local adjustments at display time. Anything else leads quickly to insanity. Usually, you also give the viewer the choice on whether to see the timestamps in their local time, or in UTC, because people who deal with a lot of timestamps generated in different parts of the globe, rapidly become pretty accustomed to reading them in UTC. The ONLY time it makes sense to use local time, is when the timestamps will only ever be generated, and viewed, in only one time zone, and both are done in the same time zone. The moment you make those timestamps accessible on a network in some way, that assumption breaks, so the smart move is to save the data in UTC, even if you think you'll only ever display it in the timezone it was created in. If the data is in UTC, then you can always upgrade the viewer later.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
HobbyProggy wrote:
That was "unbelievable tortoise crash" right?
When the tortoise[^] crashes, the world comes to an end. :~ Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Link fail.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
Rob Philpott wrote:
But good luck..!
Thanks! :) > But if you have any scheduled tasks, these will need to be rescheduled twice a year as you enter and exit daylight saving. Ugh. Another interesting wrinkle in the fabric of time. Hah! Just came up with the name for a potential article: "A Wrinkle in Time" :) Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
That's also the name of a children's book[^].
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
-
Marc Clifton wrote:
Am I missing something obvious? Have you had to deal with this issue?
Yes. You store the time in UTC and then apply any local adjustments at display time. Anything else leads quickly to insanity. Usually, you also give the viewer the choice on whether to see the timestamps in their local time, or in UTC, because people who deal with a lot of timestamps generated in different parts of the globe, rapidly become pretty accustomed to reading them in UTC. The ONLY time it makes sense to use local time, is when the timestamps will only ever be generated, and viewed, in only one time zone, and both are done in the same time zone. The moment you make those timestamps accessible on a network in some way, that assumption breaks, so the smart move is to save the data in UTC, even if you think you'll only ever display it in the timezone it was created in. If the data is in UTC, then you can always upgrade the viewer later.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
I agree with this. If you make the time as a UTC then the support person would just need to ask what time zone or state they are in and select that to do the math for them to begin the search in the local time. There are built in .net stuff to check if it is in Day light saving time or not.
-
The problem with time is that it is (of course) different depending on your time zone and daylight savings time for your region. Scenario 1: Let's say I make a blog entry at 8 AM EST, then I get on an airplane and fly to CA and set my computer to PST. When I look at my blog entry, it probably says that I made the post at 5 AM, but in my thinking, my frame of reference is still "when did I make that post (when I was in NY)?" Scenario 2: I make a blog entry at 8 AM EST, and you, living in CA, notice my blog entry, which has a time of 5 AM (because you're in PST.) That makes sense to you, in your reference frame, because you know you're 3 hours earlier. Scenario 3: I run a company that has ATM's (disclaimer: this is a good example, irrelevant to the fact that write software for ATM's, I'm not asking you to solve programming problem in that regard) in local gas stations all over the country. A customer in NY (UTC-5 at some points of the year) calls and says the ATM didn't dispense cash or a receipt! The help desk asks when they did the transaction, and they say, around 8 AM because that's the time in NY. The customer service is in CA (UTC-8 at the moment, we'll customer service in India for this scenario), so what time do they search for? Do they need to ask "where were you?" so they know the time zone and mentally subtract off 3 hours (maybe dealing a 1 AM NY transaction on 1/1/2016 now being seen in CA as 12/31/2015 10 PM????) So the question becomes, what does the user need to see, and what do they expect to see? When (harhar) does it make more sense to store date/time in the true local time, including timezone (either "PST" style notation, or "UTC-8" notation, for example, keeping in mind that not everyone knows what "UTC" is or even timezone designations like EST, MST, PST, etc. When does it make sense to convert to local time? Should both "my local time" and "transaction local time" be available for displaying/searching? Am I missing something obvious? Have you had to deal with this issue? And I haven't even touched the nightmare of daylight savings time. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventual
For that reason I never use local time and always store time values as UTC. Always. Then translating it becomes much much easier, regardless if I want to show my time (server time) for a blog post or the users time (client time) for it. Just calculate the difference in offset before displaying the time. UTC is your friend.
Jeremy Falcon
