How did I not know this?
-
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 :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
And yet, and yet.... After all these years, STILL date/time handling is an unimaginable kludge, even amongst systems from one house: Formatted date/time strings that are acceptable to SQL Server are not acceptable to MS Access JET engine (and vice versa). DATETIME objects may or may not contain the time, depending on how they are generated so you cannot reliably check that they even represent the same day without faffing about. Despite SQL supposedly being a 'standard', just wait until you try to mix T-SQL, MySQL, PostgresSQL, Oracle etc date handling. And then there's unix time, MS time, etc... Back in the early days of C/C++ I used, for many, many years, my own customised version of a Borland Date library because just no-one could handle even the differences between the UK and continental Europe, let alone other countries. I realise that a lot of these problems are not due to the coding per se - it's the weird way we humans account for and represent time and date across the globe, but you really would think that after all this time, someone, somewhere would have devised a database driven, standardised date/time handling library that could be more or less universally acceptable. We have that for most human languages - just about - after all.
-
And yet, and yet.... After all these years, STILL date/time handling is an unimaginable kludge, even amongst systems from one house: Formatted date/time strings that are acceptable to SQL Server are not acceptable to MS Access JET engine (and vice versa). DATETIME objects may or may not contain the time, depending on how they are generated so you cannot reliably check that they even represent the same day without faffing about. Despite SQL supposedly being a 'standard', just wait until you try to mix T-SQL, MySQL, PostgresSQL, Oracle etc date handling. And then there's unix time, MS time, etc... Back in the early days of C/C++ I used, for many, many years, my own customised version of a Borland Date library because just no-one could handle even the differences between the UK and continental Europe, let alone other countries. I realise that a lot of these problems are not due to the coding per se - it's the weird way we humans account for and represent time and date across the globe, but you really would think that after all this time, someone, somewhere would have devised a database driven, standardised date/time handling library that could be more or less universally acceptable. We have that for most human languages - just about - after all.
Totally true :sigh: Date handling in JavaScript is by far the worst I've come across though. Heck, I wouldn't even call it date handling, more like date-go-:elephant:-yourself X| But even in MS SQL Server, some date types recognize "2021-05-11" as a valid value, while others do not and require "20210511" :~
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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:
save data in UTC. Show data / interact with user in local.
Actually, I just got the requirements back... Save and show everything in just one date only, that of HQ :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :laugh:
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_midnightQuote:
In any case, time zones are an absolute PITA
Paraphrasing: "time zones are the worst solution except for all the other" [^] :laugh:
Mircea
Mircea Neacsu wrote:
maybe in this case they would understand the concept of time zones :laugh:
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? :sigh:
Mircea Neacsu wrote:
Paraphrasing: "time zones are the worst solution except for all the other" [^] :laugh:
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 ;)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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)
Wrong is evil and must be defeated. - Jeff Ello
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 :sigh: (Or more likely, he saw the times a week later and simply didn't think about it.)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :sigh: (Or more likely, he saw the times a week later and simply didn't think about it.)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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.
Wrong is evil and must be defeated. - Jeff Ello
-
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.
Wrong is evil and must be defeated. - Jeff Ello
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 :D And managers very sad, since date and time issues now take minutes to solve instead of months costing them sweet €€€ :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :D And managers very sad, since date and time issues now take minutes to solve instead of months costing them sweet €€€ :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
How about star dates? :D
Wrong is evil and must be defeated. - Jeff Ello
-
Nelek wrote:
save data in UTC. Show data / interact with user in local.
Actually, I just got the requirements back... Save and show everything in just one date only, that of HQ :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Well... if it is an "order" and it is written... they pay, they rule.
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
Fair enough.
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.
-
How about star dates? :D
Wrong is evil and must be defeated. - Jeff Ello
No, even Hollywood gets the same time as everyone else :~
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Well... if it is an "order" and it is written... they pay, they rule.
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.
My thoughts exactly and pretty much my company motto! :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
My thoughts exactly and pretty much my company motto! :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Offtopic... why did you remove the c# succintly link from your signature? I found it not that bad, that you should be ashamed of it ;P :-D
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.
-
Offtopic... why did you remove the c# succintly link from your signature? I found it not that bad, that you should be ashamed of it ;P :-D
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.
To make room for my newer Azure books ;)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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...
-
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 :D And managers very sad, since date and time issues now take minutes to solve instead of months costing them sweet €€€ :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Here is real time programming nightmare Arizona does not deal with daylight savings time but that is not the issue The Navajo Nation honors the concept of daylight savings time AND the Hopi Nation which sits in the middle of the Navajo Nation does not honor the concept of daylight savings time I have often wondered how you would code for this ? In one town if you cross the street you lose or gain an hour
-
Here is real time programming nightmare Arizona does not deal with daylight savings time but that is not the issue The Navajo Nation honors the concept of daylight savings time AND the Hopi Nation which sits in the middle of the Navajo Nation does not honor the concept of daylight savings time I have often wondered how you would code for this ? In one town if you cross the street you lose or gain an hour
Wow, I did not know that :wtf: Also, did you know 30 and 45 minute time zones exist? They're (whoever they are) are not making this easy for us :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
