It's about TIME for a programming question
-
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???
I was nearly 25 when I read it but still enjoyed it! :)
Cheers, विक्रम "We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread :doh:
-
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
Can't we all agree to just universally use eastern time? :-D
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
-
Can't we all agree to just universally use eastern time? :-D
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
Nish Nishant wrote:
Can't we all agree to just universally use eastern time?
I agree. That is the most sane thing to do. Unfortunately, the Brits will first be on board with the idea, then after a few years, they'll decide they want to be show their independence and pass a Brex-tix-et referendum. 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
You could always display the length of time since the post was made. I'm sure I've seen that solution used somewhere ;)
-
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
There is only one correct way: Stardate[^] :-D
Check out my blog at http://msdev.pro/
-
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
how about when a minute is longer than an hour? Falsehoods programmers believe about time: @noahsussman: Infinite Undo[^] This does happen especially when we live in this virtual server world.
To err is human to really mess up you need a computer
-
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
This is actually as complicated as you think it is! Date & Time is location specific (UTC offsets give us that adjustment). We live in FL and have a place in TN (Central time). While we are there, I keep my computer in EDT (NY Time) and talk to the clients only as if NY Time. It is simpler. Next up. Store all time as UTC type time, collect and display it as "local". And then the concept of Local to the customer is displayed to the help desk. As in, it is: xam in Bangalore (Here) 1pm in NY (Our "Company Standard Time") 4pm in Sacramento, CA (Customer Standard Time) The magic is that you have to STORE the customer address/UTC offset. And that should be something you can give them control over. In Oracle, when a session is created, you can set its default time zone, and dates/times will adjust (but this get harry over shared web connections), so a lot of our web code just handled it. Now with SaaS, you have even more issues, because you add: ?pm in Denver ("Their Company Standard Time, as opposed to ours") We fought for some time with DB rules that said "Once a record is entered, after midnight, it cannot be changed"). Yep, it was midnight in NY time, and that was 9PM in CA. They were upset in CA. Luckily they were rarely open that late. BTW, the first part of the conversation (because of all the reminders) is to confirm the time zone with the customer. Because, like myself, they could have traveled elsewhere!
-
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
TL;DR the entire discussion, but here is my take for what it's worth. First, all date/time storage should include the UTC code as others stated. As for display let's opt for both sides; display the time local to the current user *and* to the original source location. So for the example about an ATM located in New York with support in the US west coast we would see: 2016-07-29 05:00am [local EDT 2016-07-29 08:00am] That pretty much tells me everything I need to know.
-
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
Incremental searching and some AI. Built a (New Zealand postal) address lookup for a call center: if it starts with a number .... else ... etc. No other input except a single text (search) field; returns x choices which become less the more one types (incremental searching). Also deploying "shipping kiosks": missing labels usually start with a query as to kiosk and shipping destination ("time" is assumed to be recent). A fuzzy search including a $ amount and location seems like a logical place to start with ATM's... (Note that we also incrementally add "transaction info" to a central server while a shipping kiosk "session" for a given customer is in progress; so we always have "something" for a customer that started a session). Oh ... And I store several times: local (kiosk); UTC; "Server" ... To cover my ass.
-
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've worked on a number of code bases that had to properly handle and manage timestamps. I've never seen a situation yet where the correct thing to do is to store local time. Storing a common time (generally zulu time) without daylight saving time correction is what you need, with a translation from the stored time to local time (including DST correction). Almost every time related bug I've seen is related to violating this principle.
I'm retired. There's a nap for that... - Harvey