|
That one threw me for a loop!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
So I'm working on an Azure app and one thing I do (and have done for 11 years now) is use DateTime.Now, which gives me the current system date and time.
Never been an issue with WinForms apps or locally hosted apps.
It's even never been an issue in web apps where I've used it for logging and the like.
I've had to use specific time zones before, but always the user's client time zone.
In this particular case, I need to save the system/company date and time and also report this back to the user.
Azure uses UTC and I'm in The Netherlands though, so the time is always off by one or two hours (depending on summer or winter).
The fix, apparently, is this:
var timeZone = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time");
var now = TimeZoneInfo.ConvertTime(DateTime.UtcNow, timeZone);The "W. Europe Standard Time" is a bit of a magical string that will probably change in a few years when we're abolishing summer time (so make it a setting and don't hard code it!).
You can get a list of these magical strings using tzutil /l (on Windows).
I've always known DateTime.Now isn't really safe or anything, it's just never been an issue until now.
DateTime.Today is specific and accurate enough for almost everything I do.
And so I've learned how to get the date and time for a specific timezone after 11 years of programming 
|
|
|
|
|
Sander Rossel wrote: after 11 years of programming
Consider yourself lucky not having to deal with timezones until now.
You should store everything in db in UTC and then convert when needed. DateTime.UtcNow
|
|
|
|
|
We've once had someone leave somewhere at (fictional times) 14:30 and arriving at 13:45, he had driven for fifteen minutes, but went into another timezone.
So what do you do?
Correct the departure time for the arrival time zone, correct the arrival time for the departure time zone or show time zone in this user's overview for that one time every few years he takes his car on vacation (this actually happened once for thousands of users using the system for three years)?
I think we went for an asterisk with some text on hover that explained the user crossed a time zone.
Obviously, you need time zone information here.
However, what if a user changed something at home at 11:00 and then flies over to America for vacation, but remembers they should change something else.
Should they see 11:00 for the previous change, or 05:00, as that is their local time now?
If it's 11:00, which would be my preference, you might as well just store 11:00, as it's just always that, 11:00.
It's a lot easier for fetching and filtering the data if times are WYSIWYG...
|
|
|
|
|
I apologize for jumping into your conversation but I had to deal with time issues for some time and I pretend I know a few things (just my illusion, but humor me  ).
IMO both examples you give show that using UTC is the best solution. In the first one, 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.
In the second example you definitely have to enter the time zone the user wants to apply. If in addition to changing the stuff at home he has also to schedule a meeting you wouldn't want him to show up at the meeting using European time zone. Google Calendar takes this approach where each event has an associated time zone.
Quote: It's a lot easier for fetching and filtering the data if times are WYSIWYG...
Changing the filter parameters to UTC beforehand is equally easy.
Mircea
|
|
|
|
|
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"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
