<div dir="ltr"><div>It's not a lack of understanding on my part.  I have developed software that must work across different time zones, and it certainly adds a layer of complication to things, since time data must be dealt with based on location, and display of times must take into account the user's location (showing everything as GMT is the lazy way out, as it puts the burden of time conversion on the user.)</div><div><br></div><div>However, in this particular case I'm working with data that's in a single location, and only deals with days, not times.  That should be easy, since it shouldn't need to deal with time zones.  And yet, due to the way date functions work, what should be a simple calculation, such as how many days are between 1-Jun-2018 and 3-Jun-2018, needs to know the GMT offset of the machine it's running on, and fudge the date into a date/time value in order to get the correct result. (Just changing CDate() to Date(), as previously suggested, did not work for me.)  Yes, that can be done, but because of what that would have entailed, in this case I decided that porting the app to a different language was the better option for me.<br></div><div><br></div><div>IMHO all date functions should work internally as based on GMT or local time, not a mix of both.  If some functions are relying on external code that operates in a different base, then the language should be handling the offset, and not expecting the higher-level code to be doing that.  <br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 6, 2018 at 6:42 PM, Benoît Minisini <span dir="ltr"><<a href="mailto:g4mba5@gmail.com" target="_blank">g4mba5@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le 06/06/2018 à 23:35, George a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not sure why the previous, more consistent behavior, was considered a bug, and why it's deemed better now that it's 'fixed', and different date functions behave differently, and are incompatible with each other.<br>
<br>
I have an application that makes extensive use of dates and date calculations, which has worked just fine for years.  But now the bug fix has seriously broken things.  I started to kludge some of the code to make it work, but I could see I was heading down a rat-hole.  So in the end I migrated it to .NET instead.<br>
<br>
Just my $0.02<br>
<br>
</blockquote>
<br></span>
Sorry, but if you don't understand why the old behaviour is buggy, and the new one is correct, then it means that you don't understand how date & time work.<br>
<br>
It's exactly like strings and charsets.<br>
<br>
As soon as you don't deal with applications that must simultaneously work in different timezones, it's not a big deal.<br>
<br>
Otherwise you will have problems sooner or later.<br>
<br>
Regards,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Benoît Minisini</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
----[ Gambas mailing-list is hosted by <a href="https://www.hostsharing.net" rel="noreferrer" target="_blank">https://www.hostsharing.net</a> ]----<br>
</div></div></blockquote></div><br></div>