|
dandy72 wrote: Consider it stolen.
dandy72 wrote: This very aptly summarizes something I've never been able to verbalize into such few words. I could not counter that, so I just shut up
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.
|
|
|
|
|
sigh... dealing with parents is a bitch, especially so when they get old.
I won't tell you or describe my mom's last days. I was in complete denial and not the river...
You know what sucks about growing up and adulting? I hate that word, but it's perfect in the context - you might just find out that your parents weren't adulting.
Side note - predators are out there to take advantage of them. be vigilant.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: Side note - predators are out there to take advantage of them. be vigilant. I know, I try, but not easy from so far.
Luckily close cousins of mine keep an eye on him.
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.
|
|
|
|
|
charlieg wrote: adulting? I hate that word
Bill Maher claims to have coined the term. Or at least that's what he named his latest HBO special.
|
|
|
|
|
|
Time to look at Noda Time[^] perhaps?
And maybe also a skim through Jon Skeet's blog posts on the topic[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Time zones are an obsolete concept and were never a good idea to begin with.
|
|
|
|
|
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
modified 24-Jul-24 11:53am.
|
|
|
|
|
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_t to 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
|
|
|
|
|
Jeremy Falcon wrote: Well, except I believe that everything should be stored in UTC. I did this and then calculated back to the current time zone.
So then the customer called and said someone did something in the middle of the night, which was unthinkable.
After looking it up I said that person was in another time zone (on vacation) and did something that was middle of the night for him.
It was decided that everything should always be stored and shown in their HQ time zone, even when on vacation or when the apocalypse hits.
Loved the simplicity, stored current time and never looked back
|
|
|
|
|
So then display the time info in the appropriate time. There's no rule saying you can't do that. UTC is just internal to the app. Good luck doing datetime math in local time all over the world. It'll be a living nightmare.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: IMO daylight savings time did more harm than timezones. 1000% this
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.
|
|
|
|
|
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()
|
|
|
|
|
Not using UTC because some developers do stupid things, is hardly a great idea.
|
|
|
|
|
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?
|
|
|
|
|
No idea, I never said it was.
|
|
|
|
|
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.
modified 24-Jul-24 13:00pm.
|
|
|
|
|
Storing local times for any application is a bad idea. I'm sure Richard is just speaking from experience.
Jeremy Falcon
|
|
|
|
|
Why would it be a bad idea to store DateTimeOffset?
The way to store date/time I have the most experience with is DateTime stored as UTC. But I see no reason to go back to that - what is the benefit?
|
|
|
|
|
My understanding of DateTimeOffset is that it's still a local time, but with offset information. Soooooo, if I'm correct with that... The reason why it's bad is you're adding complexity for no real gain. That date time is still only relevant to you. If you have an application that is used all over the world, then you now must do two calculations to show a time to a user rather than one.
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.
|
|
|
|
|
Oh, that is clearer then.
Funnily enough I can't really find any better reason to make a decision than avoiding developers making mistakes.
|
|
|
|
|
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.
|
|
|
|