Okay, I'm daft, but I was having terrible trouble using the DateTime type to accurately handle my requirements. I tried to make everything use UTC for consistency, but it kept getting things messed up and I need reliable. That we are about to go to daylight saving here, and my code is a planner for the next week, with defaults and overrides, meant that I just couldn't get it righ.

So being daft, I wrote a SimpleDateTime class, which doesn't do anything fancy, it is a store for year, month, day, hour, min, second, and can parse ISO format strings for talking to the server, and has the common set of functions for adding an hour etc.

I mention this because it might be useful for others, but I'm not posting it right now due to some interesting flaws. First, I grabbed Tim's TimeToStr formatting code, so I hope that's okay Tim.... Second, while it does handle adding minutes and hours, so you can say IncHours(7) and it will wrap to the next day, it has nothing to handle what happens when the day goes to 32. Or 29, or whatever. I don't need that yet, so I haven't bothered yet.

But much more serious, I realised, is that this is not a base type any more. I used to pass around DateTimes like they were candy. Turns out that making them into an object means I really should manage the object lifetime. Having been using C# far too long, I am not sure what to think about this yet. My original aim was to have a "drop in replacement" for DateTime, and just put "Simple" at the start of any routine. But that's not really too good when you have EncodeTime that used to return a value, and now returns an object.

So anyway, perhaps I should really make the type an integer alias, and do my own interpretation of that somehow. Anything to get away from the browser's mangling of my dates.

--

Matthew Jones

Matthew,

To clarify these DateTime issues a little bit you need to remember that the raw value of DateTime variable is always in UTC, though you MAY set or read Date and/or Time values in local time using various functions with UTC parameter set to False, but still the raw value of DateTime variable which you pass to or receive from these functions is in UTC. In other words, some arbitrary value of DateTime variable, let it for instance be 1553866392979, is a number of milliseconds since the Unix Epoch in UTC, and it will represent different local time in different time zones.

It's a standard javascript Date object behind the scenes: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/valueof

ooptimum wrote:


> To clarify these DateTime issues a little bit you need to remember that the raw value of DateTime variable is always in UTC...

Useful to know, but it is hard to get it to be consistent for me. I also need to be able to say "is this 1 April" and "is this date the same as this calculated date", ignoring time. But 1 April kept getting to be 31 March at 23:00 and it was just too much pain, no matter how many isUTC parameters I set true.

Personally, I think the way forward would be for EWB to have pure UTC all the way, or rather "UTC or un-zoned". Then add a layer of time zone functions on top if you want something specific. UTC on storage is always the sane way. And most people don't care about time zones, they just want to know that at 5pm their time something will happen. It is of course all very complicated (I know too well), but if you cannot rely on the base then you cannot build on it.

FWIW, I never used to have this trouble, so I suspect it is related to recent changes to fix things around this. I'll revisit in EWB3.

--

Matthew Jones

"Matthew Jones" wrote:

<< Useful to know, but it is hard to get it to be consistent for me. >>

A DateTime value represents some particular "point in time" regardless of wherever you are. At any particular moment (point in time or particular raw value of a DateTime typed variable) there are 38 distinct local times around the globe representing this moment...

<< I also need to be able to say "is this 1 April" and "is this date the same as this calculated date", ignoring time.  ...  And most people don't care about time zones, they just want to know that at 5pm their time something will happen.>>

... So DateTime won't work for you well, as you need not a point-in-time, but a time-of-day, where 5pm is the same value regardless of where you are. If I had a similar task in front of me, I would probably have developed my own time storage format and my own functions for processing time in this format.

<< But 1 April kept getting to be 31 March at 23:00 and it was just too much pain, no matter how many isUTC parameters I set true. >>

Function EncodeDate is described in the help system as "The EncodeDate function returns the local or UTC date from the year, month, and day input parameters". For me it's somewhat misleading description. "The return value is a DateTime value", and as we already know, it's always in UTC. The UTC paremeter though is used to tell whether the rest of parameters are in your local time or in UTC. So if you want to encode your local 1 April you should call it as FoolsDay := EncodeDate(2019, 4, 1), and DateToStr(FoolsDay) should return you correct date string, i.e.'4/1/2019' if you didn't change FormatSettings. IOW, you should be consistent in the UTC parameter value you pass to these functions, i.e. DateToStr(EncodeDate(2019, 4, 1, true), true) still produces '4/1/2019'. Hope this helps.

ooptimum wrote:

> snip

Thanks - these things I already know, but I could not get it working consistently. May be just me, may be some interaction with my server (though the common transport was ISO format strings) but I got fed up trying.

I may rethink based on some integer, but I've done too much messing around with clever coding and an object seemed a better solution. I try not to have magic codes any more. But given the object leak problem, maybe an integer (no such thing!) of 20190401130500 would be smarter for me. Hmmm.

--

Matthew Jones

"Matthew Jones" wrote:

<< But given the object leak problem, maybe an integer (no such thing!) of 20190401130500 would be smarter for me. >>

This is exactly what I was thinking of when I wrote you about inventing own format.

On 3/30/2019 6:42 AM, Matthew Jones wrote:
> Thanks - these things I already know, but I could not get it working consistently. May be just me, may be some interaction with my server (though the common transport was ISO format strings) but I got fed up trying.
>
> I may rethink based on some integer, but I've done too much messing around with clever coding and an object seemed a better solution. I try not to have magic codes any more. But given the object leak problem, maybe an integer (no such thing!) of 20190401130500 would be smarter for me. Hmmm.

Instead of inventing your own why not just use the ISO 8601 UTC format
internally - simple string and few helper functions to make working with
is easy.

Raul

Raul wrote:

> why not just use the ISO 8601 UTC format internally

8-O

Such a good idea! Slap me sideways with a wet fish. So darned easy to make optimal too.

--

Matthew Jones

Matthew,

<< Personally, I think the way forward would be for EWB to have pure UTC all the way, >>

That's what EWB does already.  The DateTime values are simply an offset from midnight, January 1, 1970 (in UTC).

<< And most people don't care about time zones, they just want to know that at 5pm their time something will happen. >>

Then don't do anything with your date/time values, and always specify that you're working with UTC values by passing True as the UTC parameter to EncodeDateTime, DayOf, HourOf, etc.

<< FWIW, I never used to have this trouble, so I suspect it is related to recent changes to fix things around this. >>

The recent changes to EWB 2.x for dates/times was to *remove* automatic localization of standalone dates/times for datasets, so this should *improve* your situation, not make it worse.  Of course, if your issue is with date/time values (not standalone dates or times), then you need to make sure to turn *off* localization of date/time values in the EWB Web Server dataset definition, as well as in the TDataSet components in your client application:

https://www.elevatesoft.com/manual?action=viewprop&id=ewb2&comp=TDataSet&prop=LocalizeDateTimeColumns

Tim Young
Elevate Software
www.elevatesoft.com