|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Take a look at FIFA[^]'S site. At the top of the list of games there is a link that says "change to local time" or "change to your time".
You can see scheduled games in your local time (good for watching on TV), and in the local time of wherever the game will take place (good if you're planning to go there and see the game).
I saw it for the first time during the 2010 World Cup, and I like it.
In general, sport events that are broadcasted to the entire world (the Olympic games start in a few days) pose the same challenge to whoever designs their sites, which are also designed for a wide audience, so this is one place where you can look for inspiration.
JM2B,
Pablo.
|
|
|
|
|
In all the scenarios, I'd store the UTC time. And in all cases, I'm assuming you're working in a language that has a decent date/time library available. Ideally it will use something like these time zone ids that are hopefully granular enough to help sort out DST oddities like Indiana (and lots of others).
Scenario 1
In the blog's admin section, have a local time zone setting. If there's an admin user logged in, display the blog entry time in the blog's local time zone. So if you travel from NY to CA, if you go to you blog on your laptop and your admin cookie hasn't expired, you'll see the entries in your home time zone.
Scanario 2
For non-admin users, show the time in their local time zone. This shouldn't be too hard server-side if you can deduce location from their IP. If you can't, and you're lazy, and you absolutely don't ever want to show post times in the blog's 'home' time zone to users in other time zones, add <div class='post-date' data-utcmillis='12345'></div> to every entry, where data-utcmiliis is set to the number of milliseconds since Jan 1, 1970 UTC. On page load, use JavaScript to populate the date fields. The JS Date object has a Date(millis) constructor, so you can instantiate one with the UTC milliseconds value and use that to generate a local date string. So the user will either see the post date in their computer's time zone, or if they have JS disabled they'll see no date at all.
Scenario 3
Since the ATMs and branches have specific geographic locations, it's easy to localize transactions. In the case of the no receipt, no cash transaction, I think it makes sense for the customer service rep to ask the customer where it occurred, when it occurred, and the amount of cash the machine should have dispensed. Customer service needs at least some information to determine place and/or time of the transaction. Even an answer like "Last night, in New York, for $50 or $100" or "$250, some time in the past couple of days" would be enough to get started. Start the search based on the customer's card number and pull up the last 25 or 50 transactions. The where/when/amount questions will help the rep quickly scan the list for any transactions matching the customer's description. If the customer can't provide any of these details then they likely need more help than an ATM company's customer service rep can provide. 
It probably makes sense to display the transaction's local time and location, so the customer service rep can say "I see a withdrawal for $50 last night at 9:24PM from an ATM at 123 XYZ St. in lower Manhattan" without needing to do any mental time zone conversions.
|
|
|
|
|
Can't we all agree to just universally use eastern time? 
|
|
|
|
|
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
|
|
|
|
|
You could always display the length of time since the post was made. I'm sure I've seen that solution used somewhere
|
|
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
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.
modified 30-Jul-16 6:39am.
|
|
|
|
|
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
|
|
|
|
|
Yesterday, I got handed an Acer lappy, and asked to update it before the free period runs out tomorrow.
So...I back it up, and start the upgrade. It runs to 99% and stops after 4 hours. Ah. I see. Windows 7 updates...shutdown...27 updates.
Turned it this morning...same thing, 48 updates... followed by an hour to start up.
And now? Yet another 26...
Seriously Eryl? When did you last turn this thing on, 1976?
Sod this...where's that Media Creation Tool?
12 minutes later and it's downloaded the ISO and has started the verification. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Don't you just love acting as (unpaid) tech. support for all your friends and relations? 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
It would have taken a lot less time to just install Linux on the computer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
All Windows 7 SP1 updates from its release through April 2016, in a single rollup[^].
|
|
|
|
|
 So I had a BSOD problem, the hardware guy came over to handle it, and finished with a newly formatted HD!!!
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
The obvious method of thanking him would be to reformat (boot, of course) his genitalia.*
* We'd not want him to breed, anyway.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Aren't you really, really glad you do regular backups! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I'm hoping against hope that your intentions were just plain cruel.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
