|
Mircea Neacsu wrote: if you store UTC times departure and arrival times would have meaningful values. Travel time would also be correct. If you are to make a report when the traveler was away, all times should be converted to observer's time zone. The observer would be the person requesting the report or the company's HQ or whatever.
Disagree on this one.
The user checks his watch, it says 14:30, and starts driving.
Now, back at home, he wonders at what time they left exactly and is surprised to see 13:30, while he's sure it was around 14:30 (so don't adjust to user's current time).
Also, he get's a call from HQ in America who ask him why he left at 06:00 in the morning (again, they probably want to know local time (too), if not to be able to communicate).
UTC means nothing to users, they barely even know it exists.
Mircea Neacsu wrote: In the second example you definitely have to enter the time zone the user wants to apply.
Possibly... If a user changes something today at 13:00 and after that someone else sends an email they saw a bug at 12:00, you want to know the user changed it after the bug was observed to rule out any association.
In this case storing UTC and time zone information can greatly help.
You'd want HQ in America to know it was at 06:00 their time, but have the local users see 13:00.
However, if the user who made the change flies over to America, they'd probably still want to see 13:00 as that's the time they can relate to in their head, 06:00 wouldn't make sense as they were still asleep at that time.
Mircea Neacsu wrote: Changing the filter parameters to UTC beforehand is equally easy.
But wrong if the default filter is "today" and the user opens the page at 00:30 (Dutch time).
Storing UTC and time zone information never hurts, so I agree it's best practice, but whether you actually do something with it depends on each and every individual situation, unfortunately 
In my case, everyone is in the Netherlands, so I could probably get away with always storing Dutch time.
In any case, time zones are an absolute PITA 
|
|
|
|
|
I think we should agree to disagree on this one.
Quote: Also, he get's a call from HQ in America who ask him why he left at 06:00 in the morning (again, they probably want to know local time (too), if not to be able to communicate).
While it's true that most HQ are populated with morons, maybe in this case they would understand the concept of time zones 
Quote: But wrong if the default filter is "today" and the user opens the page at 00:30 (Dutch time).
But correct if you store DATETIME and filter is datetime > Dutch_midnight
Quote: In any case, time zones are an absolute PITA
Paraphrasing: "time zones are the worst solution except for all the other" [^]
Mircea
|
|
|
|
|
Mircea Neacsu wrote: maybe in this case they would understand the concept of time zones
Some idiot crossed a time zone by car and then filed a bug saying our system said he arrived earlier than he left.
The bug wasn't that they wanted to see local times, it was that the data couldn't be right.
Heck, I'm currently dealing with a report that should show invoices, but shows payments and no one is complaining.
Why do you think users understand any concept at all?
Mircea Neacsu wrote: Paraphrasing: "time zones are the worst solution except for all the other" [^]
I have an alternative, just do away with all time zones, everyone is always living at the same time.
Instead, some people would wake up at 15:00 and go to bed at 07:00 while others are awake from 08:00 to 24:00.
If someone says "can we schedule a meeting at 10:00?" a person on the other side of the world would immediately know if they're asleep at that time or not.
So instead of learning time zones you really just have to know a country's working hours.
Mircea Neacsu wrote: I think we should agree to disagree on this one.
I mostly agree with you, just not on how to present the data, which is ultimately the customer's choice anyway.
I just got my requirements back, I'm to save and show one date only, which is the local HQ date here in the Netherlands 
|
|
|
|
|
Sander Rossel wrote: and is surprised to see 13:30, while he's sure it was around 14:30
You never ever show the user UTC time. (Unless they live in Greenwich I suppose.  )
That would be a bug.
|
|
|
|
|
It is a bug, that's why I mentioned "issue" and "fix" in my original post
|
|
|
|
|
Sander Rossel wrote: UTC means nothing to users, they barely even know it exists.
Maybe not, but they should know if they pass a time zone.
They aren't that random you know. In Europe it happens when you go to and from the UK, in the US you need to travel between states.
So any user above idiot level should realize what happened as soon as they see the time is off by an hour.
(Yes, maybe my confidence in users is a bit too high, but still)
|
|
|
|
|
This user came back from a vacation in Turkey.
They probably stopped right across the border to tank some gas or get a sandwich, I don't know.
I do know this user filed a bug because he arrived earlier than he left, which could never be correct.
The concept of time zone was obviously lost on him as we had to explain to him that he crossed it
(Or more likely, he saw the times a week later and simply didn't think about it.)
|
|
|
|
|
Sander Rossel wrote: The concept of time zone was obviously lost on him as we had to explain to him that he crossed it
You simply cannot compensate for every or any type of idiocy in your programs. Just make sure that the data is stored correctly.
Also, be happy we have time zones.
In Sweden we got the same A time zone 1879. It was the railway companies that introduced that. They found it impossible to create reliable time tables when local time varied from east to west.
Before that every town had their own time. People looked at the church tower and set their pocket watches after that. And the sexton usually set it after the sun.
|
|
|
|
|
I posted an alternative to timezones in another reply in this thread.
Sander Rossel wrote: I have an alternative, just do away with all time zones, everyone is always living at the same time.
Instead, some people would wake up at 15:00 and go to bed at 07:00 while others are awake from 08:00 to 24:00.
If someone says "can we schedule a meeting at 10:00?" a person on the other side of the world would immediately know if they're asleep at that time or not.
So instead of learning time zones you really just have to know a country's working hours.
I think such a system would make programmers all around the globe very happy 
And managers very sad, since date and time issues now take minutes to solve instead of months costing them sweet €€€
|
|
|
|
|
How about star dates?
|
|
|
|
|
No, even Hollywood gets the same time as everyone else 
|
|
|
|
|
Just imagine the political arguments over who gets their time as THE time!
Also, would people be able to cope with the date changing in the middle of the working day?
|
|
|
|
|
StarNamer_ wrote: Just imagine the political arguments over who gets their time as THE time!
Yeah, it probably couldn't be done because people are trash (personally, I'd say we all go to UTC).
StarNamer_ wrote: Also, would people be able to cope with the date changing in the middle of the working day?
Maybe you could slide into it, like shift one hour each month.
Now THAT would be hell to put into systems, but at least it's only for a year (and shorter for most regions)
|
|
|
|
|
I don't remember exactly which solution did this right to me, but I think it was google calendar.
The way it handled it was that when I travelled, it detected I was in a different time zone than of where the event was registered and showed a hint saying that the event was registered in a different timezone and displayed the time of that timezone along the time on my current timezone.
For that to be possible not only you save the UTC value of the event, but the also the timezone of the location when it happened. Then with the current timezone you can do all types UX improvement for this type of scenario, without cluttering it when it's not necessary.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
This is why the format you should use isn't raw UTC< but DateTimeOffset (C#) / datetimeoffset (mssql) / whatever your platform equivalent is, with the offset used to record the timezone where the records data originated from.
Sander Rossel wrote: Disagree on this one.
The user checks his watch, it says 14:30, and starts driving.
Now, back at home, he wonders at what time they left exactly and is surprised to see 13:30, while he's sure it was around 14:30 (so don't adjust to user's current time).
Also, he get's a call from HQ in America who ask him why he left at 06:00 in the morning (again, they probably want to know local time (too), if not to be able to communicate).
UTC means nothing to users, they barely even know it exists.
Initial departure time is stored as 14:30 CEDT when the user departs from Spain, and 13:45 WEDT on arrival in Portugal.
The UI can then show times in the time they were reported at, the users current time, or if you're feeling overly elaborate an arbitrary user selected one.
So the user making the drive in Portugal could see 14:30 CEDT to 13:45 WEDT (actual time stamps), or 13:30 WEDT to 13:45 WEDT (current local time), or 14:30 CEDT to 14:45 CEDT (user configured to use CEDT as their preferred timezone).
The user how made the drive now back home in Spain could see 14:30 CEDT to 13:45 WEDT (actual time stamps), or 14:30 CEDT to 14:45 CEDT (current local time), or 14:30 CEDT to 14:45 WEDT (user configured to use CEDT as their preferred timezone).
The bean counter user at the HQ in the US somewhere in the rocky mountains would see, 14:30 CEDT to 13:45 WEDT (actual time stamps), or 6:30 MST to 6:45 MST (current local time), or 8:30 EDT to 8:45 EDT (user configured to use CEDT as their preferred timezone). If the users in the HQ are dense enough to be confused by seeing 6:30 MST for an overseas timestamp update the UI to show two values at once Start in your timezone: 6:30 MST, Start in drivers timezone: 14:30 CEDT, and optionally add the "driver crossed timezones hint" as well.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Can't CEDT or WEDT change?
Like we're now talking about dropping summer time in The Netherlands/Europe?
You'd at least need a date to get it correct.
You wouldn't have this issue if you stored UTC and time difference separately (you'd always know the time as it was when the user left/arrived, which would be UTC + difference and you can always go from UTC to anything else).
|
|
|
|
|
When the timezone data changes there is a corresponding OS level change that will handle it and it know at what point the DST was dropped. So calculations will know if it was in effect or not. It's not rocket science...
|
|
|
|
|
Time is not a unit the same way that weight is not a unit. Using local time results in data that has multiple unit types in it. This would be like storing a number in the weight column and having some people enter kg, some entering grams and some entering pounds. Always store time in UTC and convert to local time for display. That way all relative times are accurate.
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I second Sean’s opinion: always use UTC. Otherwise, sooner or later, you will have to deal with issues like “is this date before or after the time zone rules have changed?” (or changed for the third time).
Mircea
|
|
|
|
|
I'm sure you already know this, but you can also test for IsDaylightSavingTime on the returned TimeZoneInfo.
I built a web-based (Azure) timeclock app several years ago and got schooled in handling times/timespans.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
|
Never heard of it, but it must be good if it's Jon Skeet's!
Trying to keep this as simple as possible though 
|
|
|
|
|
I heavily second this suggestion - the built in DateTime has a bunch of deficiencies this blog post by Jon Skeet: Noda Time: What's wrong with DateTime anyway? is, as ever excellent.
Even with NodaTime I work in Instants (analogous to UTC) as much as possible, converting from local dates on the way in and to local dates on the way out.
|
|
|
|
|
Didn't you know about DateTime.ToLocalTime Method (System) | Microsoft Docs[^] ?
And by the way... as someone who has traveled quite a bit (crossing time zones)... please listen to the guys...
TL;DR; save data in UTC. Show data / interact with user in local.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: Didn't you know about DateTime.ToLocalTime Method (System) | Microsoft Docs[^] ?
That's a giant trap if you're doing web work because it puts data in whatever is the servers timezone not the users - which can be especially fun if the hosting provider has the server running on UTC rather than the datacenter local TZ.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
