|
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"
|
|
|
|
|
|
Never heard of it, but it must be good if it's Jon Skeet's! 
Trying to keep this as simple as possible though 
|
|
|
|
|
I heavily second this suggestion - the built in DateTime has a bunch of deficiencies this blog post by Jon Skeet: Noda Time: What's wrong with DateTime anyway? is, as ever excellent.
Even with NodaTime I work in Instants (analogous to UTC) as much as possible, converting from local dates on the way in and to local dates on the way out.
|
|
|
|
|
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: 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.
|
|
|
|
|
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
|
|
|
|
|
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! 
|
|
|
|
|
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  
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
|
|
|
|
|
And I thought it was latitude and longtitude (longitude).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
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 
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 | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) -yourself 
But even in MS SQL Server, some date types recognize "2021-05-11" as a valid value, while others do not and require "20210511" 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
