|
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.
|
|
|
|
|
Well, I don't know enough about the C# structures to speak intelligently on the matter. So, there's an 82.5% chance I'm talking out of my arse.  But, generally speaking, it's bad to store anything in local time. And trying to make code idiot proof is impossible, especially at the expense of making the code harder to follow. That's what code reviews are for. You're adding more complication to the product just because of a DateTimeKind.Unknown situation when it's so much easier to just keep everything in UTC.
Jeremy Falcon
|
|
|
|
|
I was using DateTime in 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
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
A local time in c# does not represent a unique point in time as it can't store A and B times when transitioning from daylight saving time to standard time.
So once you go from local to universal... Good luck.
But sure, maybe they chose an implementation that happens to always work in that specific case... But just realizing this is not clear is enough for me to stay clear of that problem.
|
|
|
|
|
Wouldn't that make UTC more appealing then? Then you only have to do one conversion when going back to local.
Jeremy Falcon
|
|
|
|
|
It seems you are under the impression I am preferring local time instead of UTC time. I do not.
I prefer DateTimeOffset over DateTime.
With DateTime you have to be carefull not making mistakes. DateTimeOffset eliminates several of these possible mistakes.
|
|
|
|
|
lmoelleb wrote: It seems you are under the impression I am preferring local time instead of UTC time. I do not.
Gotcha
Jeremy Falcon
|
|
|
|
|
Be thankful Special and General Relativistic effects are not considered.
"I once put instant coffee into the microwave and went back in time." - Steven Wright
|
|
|
|
|
|
If you care for vegetable instruments, you should check up The Vegetable Orchestra.
The Vegetable Orchestra Literally Plays with Their Food[^] (YouTube) is a nice presentation of how they make and use their instruments. For a concert performance without disturbing voice comments, try The Vegetable Orchestra - Transplants[^] - there are several others at YouTube.
This definitely is not "Techno" style - all their instruments are unplugged, all acoustic. I didn't see them playing water melon, but it seems like their standard bass drum is a pumkin.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
I refuse to clink on that lick 
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.
|
|
|
|
|
Fair enough if you reject any link to YouTube. I never heard of malware spread by ordinary YouTube watching, but I may be ignorant. If what you intend to say is that 'I have against YouTube in general, and I will not support it by navigating to it', you are of course welcome to - but you draw much more attention to YouTube that way, making people a lot more aware of it. Either you should state why you refuse to watch YouTube movies, or people will as 'Why not? There is no reason for your rejection'.
Besides: I could of course repeatedly state that my favorite hobby is to not collect stamps. Who would care about what I do not do? Who would care about your not watching a YouTube movie?
If you do not trust it to be a YouTube link even if the bottom line (in most browsers, or a separate field) says so, then the implication is that you do not trust any new link, no matter how authenticated it is - only those links that you know from before. That would limit your web browsing down to what I would consider useless. It may be sufficient for you, though!
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
