Date Time Picker standard time to daylight savings time problem
-
Hi everyone, I created a report program where a from/to date range is selected to display that range of reports to a listview control. The problem: If that range crosses a shift from standard time to DST you lose a day. Example: Mar 11 2023 to Mar 12 2023 time period is 0 days and only Mar 11 2023 is shown even though the range is 11 to 12th. Does anyone know what or if there is a fix for this? This is my first post so please advise if I am not using this correctly. Thank you, Steve
Are there any reports in the data store dated Mar 12th?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Hi everyone, I created a report program where a from/to date range is selected to display that range of reports to a listview control. The problem: If that range crosses a shift from standard time to DST you lose a day. Example: Mar 11 2023 to Mar 12 2023 time period is 0 days and only Mar 11 2023 is shown even though the range is 11 to 12th. Does anyone know what or if there is a fix for this? This is my first post so please advise if I am not using this correctly. Thank you, Steve
You provide to little information to be able to help. What data store are you using? How are the dates stored? In what time units you calculate (days, hours, seconds)? For instance from Mar 11, 2023 03:00:00 to Mar 12, 2023 03:00:00 there are only 23 hours so your system might say it's less than a day. Having worked for a long time with time, my advice is to always use UTC. It's the only (almost) uniform time scale and computations to and from local time can be handled relatively easy.
Mircea
-
You provide to little information to be able to help. What data store are you using? How are the dates stored? In what time units you calculate (days, hours, seconds)? For instance from Mar 11, 2023 03:00:00 to Mar 12, 2023 03:00:00 there are only 23 hours so your system might say it's less than a day. Having worked for a long time with time, my advice is to always use UTC. It's the only (almost) uniform time scale and computations to and from local time can be handled relatively easy.
Mircea
Mircea Neacsu wrote:
always use UTC
When I suggested that to the designers and team leaders driving the last commercial project that I worked on, the answer was, "No, we need to keep track of transactions by local time". :rolleyes: Fortunately the project was canned not long afterwards.
-
Mircea Neacsu wrote:
always use UTC
When I suggested that to the designers and team leaders driving the last commercial project that I worked on, the answer was, "No, we need to keep track of transactions by local time". :rolleyes: Fortunately the project was canned not long afterwards.
Richard MacCutchan wrote:
we need to keep track of transactions by local time
Not surprised. I've seen the same attitude by one of the habituals in the lounge. People don't understand that local time is mostly an expression of political will rather than a time scale.Even with UTC some forget about the occasional leap second but at least Earth is not playing any political games. Best put by Dr Who: Big ball of wibbly wobbly... time-y wimey... stuff.[^]
Mircea
-
Are there any reports in the data store dated Mar 12th?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
Apologies yes! Mar_11_2023_hst.txt and Mar_12_hst.txt I saw someone else had commented that maybe my time in hours is not 24 since you lose the 2am hour from daylight savings time. I think that may be the problem. i will post when i get a chance to look at it. Thank you.
-
You provide to little information to be able to help. What data store are you using? How are the dates stored? In what time units you calculate (days, hours, seconds)? For instance from Mar 11, 2023 03:00:00 to Mar 12, 2023 03:00:00 there are only 23 hours so your system might say it's less than a day. Having worked for a long time with time, my advice is to always use UTC. It's the only (almost) uniform time scale and computations to and from local time can be handled relatively easy.
Mircea
Hi Mircea, I think you might be onto something here! I will check my code and probably even use UTC and end this little problem. Thank you.
-
Richard MacCutchan wrote:
we need to keep track of transactions by local time
Not surprised. I've seen the same attitude by one of the habituals in the lounge. People don't understand that local time is mostly an expression of political will rather than a time scale.Even with UTC some forget about the occasional leap second but at least Earth is not playing any political games. Best put by Dr Who: Big ball of wibbly wobbly... time-y wimey... stuff.[^]
Mircea
-
Hi Mircea, I think you might be onto something here! I will check my code and probably even use UTC and end this little problem. Thank you.
-
As Mircea says, "always use UTC". The only time you need to convert it to local time is when you want to display it to one of those insignificant, and simple, blobs of protoplasm that inhabit the earth.
Looks like someone here doesn't like UTC and down-voted both my answer and yours. Oh well, can't please everyone! :laugh:
Mircea
-
Looks like someone here doesn't like UTC and down-voted both my answer and yours. Oh well, can't please everyone! :laugh:
Mircea
