Your time string doesn't fully specify a time point. You can change it to:
iss >> std::chrono::parse (format, d);
and d is correctly calculated as 25731, which represents your time converted to seconds.
In the docs the key point is:
If from_stream fails to parse everything specified by the format string, or if insufficient information is parsed to specify a complete result, or if parsing discloses contradictory information, is.setstate(std::ios_base::failbit) is called.
If it supports text, then use a font icon; e.g. Emoji, etc.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Excuse me for asking, but why would you still be using VS6? Seems to be a 20+ years old product and there have been innumerable versions after that. I seems to remember having used it long time ago but any memory has been lost in the darkness of time.
I'm sure you must have a good reason and I'm asking only out of curiosity. Please don't misinterpret it as a critique or something.
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.
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.
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.
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.
I’m building a chart for my game I’m hoping it will help me understand various parts of the game and how they interact. Please forgive my newbish approach. Could you please take a look and tell what you think?
Raw collision detection->Optimised collision detection->Collision Detection events
Raw line of sight check->Optimised line of sight check->Los events
CD and Los events->Units ->Response
Factory algorithm-> spawn units
Last Visit: 31-Dec-99 18:00 Last Update: 2-Oct-23 19:10