[Gambas-user] Using dates in Gambas

[Jorge Carrión]

In fact in Sqlite *all* data types are stored as characters and defined by
"data affinity".
Very well explained here:
https://www.sqlite.org/datatype3.html

Regards

El mié., 22 may. 2019 a las 15:37, Cedron Dawg (<cedron at exede.net>)
escribió:

> Hi Benoit,
>
> I think you should have said: "In Gambas, dates are NOT strings", because
> in SQLite they are stored as such, which can make your proclamation
> confusing.
>
> In my own case, I haven't started using dates yet.  I was/am assuming that
> the Gambas' Result class would take care of any converstions:
>
> I think this is true:
>
>   1) Gambas stores dates in its own internal format
>
>   2) Databases store dates in their own (inconsistent across different DB
> types) formats.
>
>   3) The Gambas database objects will convert for you under the covers.
>
> When you say "Gambas has to create the date fields", is that short hand
> for "In database with more than one DATE type, Gambas will only work with
> one."?
>
>
> Now, for the local vs UTC mess.  I got bit early on by some functions
> being UTC aware and others not.
>
> Perhaps there should be two Date types in Gambas.  The regular Date
> meaning local time, i.e. locale unaware, and a UtcDate which is locale
> aware.  That way it would be really clear which one you are holding and the
> rules for display and database storage could be defined inpependently for
> both.
>
> Just a thought.
>
> Ced
>
> P.S.  I've found working with databases delightfully easy in Gambas.
>
> P.P.S  I haven't done any yet, but I presume that Gambas also handles
> boolean value storage conversions as well.
>
>
> ----- Original Message -----
> From: "Benoît Minisini" <g4mba5 at gmail.com>
>
> OK, you read it, but I'm not sure you understood it then.
>
> "Dates are NOT strings" is the name of the first paragraph. Look at your
> words, you are talking about sending / receiving dates as strings from
> sqlite.
>
> On the other hand, I didn't write the database-specific paragraph, so I
> will explain you:
>
> 1) You must send to the database and receive from it dates, not strings.
>
> 2) You have to create the database from Gambas, by using Date fields.
>
> 3) The gambas database component will take care of using the accurate
> date/time SQL type that works with your specific database.
>
> 4) To write a date to the database, you use: 'Result!Field = SomeDate'.
>
> 5) 'SomeDate' must be a date. If you use a string, you deal with
> implicit conversion.
>
> 6) To read the date back, you use 'SomeDate = Result!Field'.
>
> 7) 'SomeDate' is still a date. Now if you want to show the date to the
> user, (or to you), you have to use PRINT, Str(), or Format().
>
> 8) SQL date/time field types are a mess (as everything in SQL). The
> gambas database component will store the date in the database IN LOCAL
> TIME. Which is a stupid thing as soon as your database is accessed from
> different timezones. You have to manually convert the dates from the
> timezone of the server that writes to the database to the timezone of
> the client that reads it. An option for automatically doing that must be
> added to the Gambas database driver!
>
> Are things more clear now?
>
> --
> Benoît Minisini
>
> ----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----
>
> ----[ 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/20190523/f95eb0da/attachment.html>