I have anxiety now...
-
The Problem with Time & Timezones - Computerphile - YouTube[^] And yeah, been there done that (luckily not all the exceptions discussed in this video...) :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
-
I disagree. At the time, "Railway Time" was an excellent response to the issue where every town had their own idea of what the current time was, which made train scheduling confusing for both the railway companies and the traveling public. Nowadays, though, you should probably store DateTime objects in UTC or Unix-Epoch or some other non-local time format, and convert to local time as needed. I've seen various arguments for doing everything in UTC, but I can't see that as gaining traction. People, being people, are going to want to have solar noon more-or-less match the clock reading 12:00 [Pedantic note: noon is neither AM (Ante-Meridian: before midday) or PM (Post-Meridian: after midday)]. Though maybe that's an old fogey perspective, and it will be like the metric system, with eventually only the US sticking to the old ways.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Totally agree. Well, except I believe that everything should be stored in UTC. Just get used to it already. But, especially before the Internet and globalization, anti-timezone peeps act like not having a timezone would be better. But, just imagine the chaos of morning sunrise happening at 11:00PM. It's just trading one confusion for another. People want to act smart by looking behind them (easy to do) and insulting things. But, I can promise, given the state of the world, most everyone would be agreeing to use them if they were alive and well during that time. IMO daylight savings time did more harm than timezones. Again, I can see why it was created. But, it caused more issues than timezones. Timezones were never really an issue.
Jeremy Falcon
-
The Problem with Time & Timezones - Computerphile - YouTube[^] And yeah, been there done that (luckily not all the exceptions discussed in this video...) :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
It's a YT video. It's supposed to make things dramatic and conflicted. Any real professional programmer should know how to deal with timezones this day and age. There's no excuse, unless you're an intern or something like that.
Jeremy Falcon
-
Even outside time zones it's all hard enough. We are now contending with the slowing of the earth spinning causing days to be ms longer. We'll soon start to contend with time in space, not to be confused with space-time.
jochance wrote:
We are now contending with the slowing of the earth spinning causing days to be ms longer.
Most people don't realize that. Every year gets a bit longer. It's something like a day getting longer by about 1.8 milliseconds per century, which is something like 657.45 MS (almost a second) every 100 years. So, in the future, we may need a new calendar system to account for it.
Jeremy Falcon
-
I disagree. At the time, "Railway Time" was an excellent response to the issue where every town had their own idea of what the current time was, which made train scheduling confusing for both the railway companies and the traveling public. Nowadays, though, you should probably store DateTime objects in UTC or Unix-Epoch or some other non-local time format, and convert to local time as needed. I've seen various arguments for doing everything in UTC, but I can't see that as gaining traction. People, being people, are going to want to have solar noon more-or-less match the clock reading 12:00 [Pedantic note: noon is neither AM (Ante-Meridian: before midday) or PM (Post-Meridian: after midday)]. Though maybe that's an old fogey perspective, and it will be like the metric system, with eventually only the US sticking to the old ways.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
I use DateTimeOffset instead of storing in UTC. Too many things can go wrong in the conversion when using DateTime. I have seen highly experienced developers doing stupid things like DateTime.Now.ToUniversalTime()
-
Why would it be better to use DateTime than DateTimeOffset? Edit: and why would you not want to minimize the possibility of doing stupid things?
-
It's a YT video. It's supposed to make things dramatic and conflicted. Any real professional programmer should know how to deal with timezones this day and age. There's no excuse, unless you're an intern or something like that.
Jeremy Falcon
-
Yet I have seen a developer I would clarify as highly competent do "DateTime.Now.ToUniversalTime()". I have seen code break because it did not handle DateTimeKind.Unknown and some upstream code changed. Yes, it is quite simple, yet mistakes happens.
lmoelleb wrote:
Yet I have seen a developer I would clarify as highly competent do "DateTime.Now.ToUniversalTime()".
That in and of itself isn't bad. It would be context dependent as to whether that's bad or not.
lmoelleb wrote:
Yes, it is quite simple, yet mistakes happens.
For sure, but it's not as bad as some would suggest. I'd argue dealing with OS API compatibility or browser compatibly issues are far more involved (well not as much as it used to be).
Jeremy Falcon
-
I use DateTimeOffset instead of storing in UTC. Too many things can go wrong in the conversion when using DateTime. I have seen highly experienced developers doing stupid things like DateTime.Now.ToUniversalTime()
lmoelleb wrote:
I use DateTimeOffset instead of storing in UTC.
I don't do .NET these days, but would that not use the same conversions internally to figure out the offset? So, what's the advantage over just converting to UTC and sticking with it?
Jeremy Falcon
-
You said it was not a great idea? I agree it is hard to clasify as "great", just an extremely simple way to minimize a problem.
Storing local times for any application is a bad idea. I'm sure Richard is just speaking from experience.
Jeremy Falcon
-
I use DateTimeOffset instead of storing in UTC. Too many things can go wrong in the conversion when using DateTime. I have seen highly experienced developers doing stupid things like DateTime.Now.ToUniversalTime()
I was using
DateTimein a generic way, meaning an object that expresses a point in time, whether a Database object, program variable or datum in a flat file. I did not intend to refer to any specific version of a Date/Time object."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
Totally agree. Well, except I believe that everything should be stored in UTC. Just get used to it already. But, especially before the Internet and globalization, anti-timezone peeps act like not having a timezone would be better. But, just imagine the chaos of morning sunrise happening at 11:00PM. It's just trading one confusion for another. People want to act smart by looking behind them (easy to do) and insulting things. But, I can promise, given the state of the world, most everyone would be agreeing to use them if they were alive and well during that time. IMO daylight savings time did more harm than timezones. Again, I can see why it was created. But, it caused more issues than timezones. Timezones were never really an issue.
Jeremy Falcon
Jeremy Falcon wrote:
everything should be stored in UTC
I've been using Unix Epoch (seconds since Jan 1, 1970 UTC+0) i.e. a
time_tto store most times since the late 80's. Which is the same idea. It represents a fixed moment in time, and what semantic interpretation is up to any locale information that's active at any given moment."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
Even outside time zones it's all hard enough. We are now contending with the slowing of the earth spinning causing days to be ms longer. We'll soon start to contend with time in space, not to be confused with space-time.
jochance wrote:
We'll soon start to contend with time in space, not to be confused with space-time.
[A moon time zone? Why NASA is racing to set one.](https://www.usatoday.com/story/graphics/2024/04/23/why-moon-time-zone-is-needed/73288518007/#:~:text=On Earth%2C Coordinated Universal Time,one or multiple time zones.)
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
You said it was not a great idea? I agree it is hard to clasify as "great", just an extremely simple way to minimize a problem.
No, what I actually said was
Quote:
Not using UTC because some developers do stupid things, is hardly a great idea.
.My point being that to do, or not do, something because some other developer may make a mistake, or do something stupid, is not really good decision making. It was not meant to be specific to DateTime or DateTimeOffset.
-
Storing local times for any application is a bad idea. I'm sure Richard is just speaking from experience.
Jeremy Falcon
-
No, what I actually said was
Quote:
Not using UTC because some developers do stupid things, is hardly a great idea.
.My point being that to do, or not do, something because some other developer may make a mistake, or do something stupid, is not really good decision making. It was not meant to be specific to DateTime or DateTimeOffset.
-
lmoelleb wrote:
I use DateTimeOffset instead of storing in UTC.
I don't do .NET these days, but would that not use the same conversions internally to figure out the offset? So, what's the advantage over just converting to UTC and sticking with it?
Jeremy Falcon
The main advantage is that it natively protect against mistakes. It does not use the same logic internally as DateTime - it stores the offset instead of DateTimeKind. You never have to deal with DateTimeKind.Unknown (primary reason for mistakes I have seen). You never have some database layer having to be told if it is local time or utc. If some idiot use local time... Then nothing happens because it still accurately represents a unique point in time - no matter where in the world that local time was used.
