<div dir="ltr"><div>This is what broke my code:</div><div>    <span style="font-family:monospace,monospace">Dim Dat1 As Date<br>  Dat1 = "6/1/2018"<br>  Message("Dat1: " & Dat1 & " Formatted: " & Format(Dat1, "mm/dd/yyyy"))</span><br></div><div><br></div><div>Result: Dat1: 06/01/2018  Formatted: 05/31/2018</div><div><br></div><div>I stand corrected on the DateDiff issue; my code was not using it because it's counting days based on a schedule of working/non-working days.  Since I hadn't gotten past the 'Format' issue, I never dove into that part of the code to see why it was breaking, other than seeing that day calculations, which used to work, no longer did since the patch.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 7, 2018 at 8:42 AM, 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 07/06/2018 à 11:55, George a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.)<br>
<br>
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>
</blockquote>
<br></span>
You get the difference between two dates with DateDiff(). Where did you see that you had to deal with timezones?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
IMHO all date functions should work internally as based on GMT or local time, not a mix of both.  <br>
</blockquote>
<br></span>
All date & times are internally stored in UTC.<br>
<br>
But all date & times functions that deal with date & time string printed representation (Str & Val & Format) have to supposed a local date, because none of them have an optional argument that would tell the timezone.<br>
<br>
Date & times functions using a non-printed string representation (CStr & CDate) assume an UTC timezone.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Benoît Minisini<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>