[Gambas-user] Format function changes date value

[George]

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.)

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.

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.


On Wed, Jun 6, 2018 at 6:42 PM, Benoît Minisini <g4mba5 at gmail.com> wrote:

> Le 06/06/2018 à 23:35, George a écrit :
>
>> 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.
>>
>> 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.
>>
>> Just my $0.02
>>
>>
> 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.
>
> It's exactly like strings and charsets.
>
> As soon as you don't deal with applications that must simultaneously work
> in different timezones, it's not a big deal.
>
> Otherwise you will have problems sooner or later.
>
> Regards,
>
> --
> Benoît Minisini
>
>
> ----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20180607/bbf43a7d/attachment.html>