[Gambas-user] CDate Documentation

Jussi Lahtinen jussi.lahtinen at gmail.com
Fri Nov 18 19:43:09 CET 2022


If you look at how calendar time works example in GNU C library, you will
see that timezone is always parameter or conversions are only manual.
Benoit has rejected this approach for Gambas because he doesn't (want to?)
understand the problem. There is no good and easy way to deal with this
problem in Gambas.
It is a problem by design. But of course everything is doable, just not
always reasonable.

Here this will help you:
Print  Val("11/18/2022 15:00:00")        --> 18.11.2022 15:00:00

But there is no solution for the core problem.


Jussi



On Fri, Nov 18, 2022 at 6:58 PM Claus Dietrich <claus.dietrich at freenet.de>
wrote:

> First upon all I have to apologize that I always open a new thread
>
> with my posts. This will be the last one with this problem.
>
> On /Thu Nov 17 14:47:24 CET 2022 Benoit wrote:/
>
> >By the way, does the last commit help you with dealing with CDate()?
>
> Sorry, I had to wait until today for an up-to-date ppa-master.
> Thanks for your efforts, but your modification seems to relate to
> posts from others and I don't understand the approach:
>
> 1. To me, the manual entrance of a static UTC offset makes things
> worse because the daylight saving is changing over the year. Hence
> this syntax will provide inconsistent results over the year, also
> within the own time zone.
>
> 2. To obtain a correct UTC+n parameter for a different time
> zone and a different date/ time is practically feasible. I have
> developed such a heavy weight routine based on tzdata but I
> am assuming that nobody would use it in conjunction with the
> CDate function.
>
> I was just looking for a small modification where the resulting
> Date (as datatype ) is not shifted by the current time zone offset
> of the platform.
>
> For a moment I thought about an optional boolean CDate parameter,
> which tells the function, not to shift to UTC. This would maintain
> compatibility, but rather looks like patch work, i.e.:
>
> Print  CDate("11/18/2022 15:00:00")        --> 18.11.2022 16:00:00
> Print  CDate("11/18/2022 15:00:00", False) --> 18.11.2022 15:00:00
>
> On Thu Nov 17 14:44:12 CET 2022 Benoit wrote:
> >Actually you should never use the CDate() function. Because it only and
> >arbitrarily interprets strings as UTC dates in the american format.
>
> I fully agree and that's the reason for my posts.
>
> Best regards
> Claus
>
>
>
>
>
>
>
>
>
>
>
>
>
> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20221118/f1da6aac/attachment-0001.htm>


More information about the User mailing list