Xojo.Core.Date Question

I’m trying to figure out how to get Xojo.Core.Date to output text into the old Date.SQLDateTime format. It appears that this is not possible. Using the built-in methods.

Am I missing something or is this an oversight in Xojo.Core.Date?

Date.ToText defaults to the SQLDateTime format.

Hhhmm…seems counterintuitive. Plus, it doesn’t solve the problem of wanting only SQLDate unless I split it myself.

I would argue that this is a poorly named method. ToText means something in one case and ToText(…all the options…) in another.

I think having ToSQLDateText and ToSQLDateTimeText would make more sense.

ToText with no locale passed means a Text used for machine processing (including on other types- no symbols, separators, etc)- it’s pretty clean and consistent. I think you might like it when you get used to it. I was eventually won over myself :slight_smile:

While you can request the form without the time, I’m wondering what scenarios where that’s required? Most DBs would just store the date part for a date-only field anyway- at least that I think of off the top of my head.

SQLite might store the entire string regardless. I’ll have to check on that.

Oh, probably. But it’s been a pain in the a** to convert date/time processing in ActiveRecord over to using Text and Xojo.Core.Date. Everything else has been easy to convert, except for that.

While i don’t recall the specifics I have had uses for that multiple times past that did not involve DBs where that was just the easiest way to accomplish what needed done.

it is things like this that will make porting to the new framework more work than it needs to be.

  • Karen

Agreed. While it’s simple to just say the SQLDatetime is good enough for most cases, it means that the new framework doesn’t have the same functionality. Yes, it’s a simple addition to my code but it means that the new Date class doesn’t quite have the same built-in functionality.

Is it likely that the new built-in Date class will gain the same functionality as before any time soon? Or is it pretty much mandatory that the conversion will have to be done when moving to the latest version?

Tim

Well, the new date class has more functionality than the existing date class IMO. The only issue I have is with the sqlDate not being available.

You don’t have to do anything with the new framework yet unless you are doing iOS.

You don’t have to, but some may want to write new desktop code with an eye to the future. I know that is something I now think about.

Absolutely, which is why I’ve been looking into it. That and I’ll need to do a training video on it sooner or later which is why I end up asking the silly questions…

Hi all,

I agree - it is a move to the future. In my case, I make extensive use of both Date.SQLDate and Date.SQLDateTime. Lots of code to change - which will eventually have to be done. So if there was a chance that these might be added to the new classes, then I would not go through the pain of making the changes. Sooner is usually better than later, since I usually forget these changes were made and find out sometime in the future when they are depreciated and no longer available…

Thanks all,
Tim

“ios sqldate” does not lead any result in Feedback.

Would it not be time to log a feature request, to have some chances that Date.SQLDate and Date.SQLDateTime make their way into a next release ?

Done. <https://xojo.com/issue/37521>

And as I suspected, SQLite doesn’t care if your field is defined as a date vs timestamp field. It happily puts the full SQLDateTme string into the fields.

So from an SQLite perspective the Xojo.Core.Date.ToText fails.

And since the new date class doesn’t work with the DatabaseRecord or Recordset classes the only way to insert/update data is via SQL. This makes the ToText method really inconvenient because if I just want a date I have to come up with my own method to strip it out or create my own.

In my mind, the machine formatted (no locale) ToText should probably respect a TimeStyle of None for those cases- which it doesn’t, yet.

Remember the idea here is to be consistent- for any type (not just Date) you can can call ToText and get a machine ready Text to work with. In that respect I’m not sure Date should have “SQLDate” any more than other types should- you should be able to call ToText on any type have it work in most cases. All your code of different types would all be calling the same thing to get their machine-ready textual representation. But until it respects a TimeStyle of None (or we add the helper method directly!) you’d do something like:

Function ToTextDateOnly(Extends myDate As Xojo.Core.Date) As Text Dim dtParts() As Text = myDate.ToText.Split(" ") Return dtParts(0) End Function

I had another idea that may be slightly better that I talked about at http://www.bkeeneybriefs.com/2014/12/xojo-core-date/

Extends the Locale to have None, and the FormatStyles to have an SQL option.

dim d as Xojo.Core.Date = Xojo.Core.Date.Now dim t as text = d.ToText(Locale.None, Date.FormatStyles.SQL, Date.FormatStyles.SQL)

[quote=155202:@Travis Hill]Function ToTextDateOnly(Extends myDate As Xojo.Core.Date) As Text
Dim dtParts() As Text = myDate.ToText.Split(" ")
Return dtParts(0)
End Function[/quote]

That works too :

Function SQLDate(Extends myDate As Xojo.Core.Date) As Text Dim dtParts() As Text = myDate.ToText.Split(" ") Return dtParts(0) End Function

Function SQLDateTime(extends d as xojo.core.date) As text return d.totext End Function

The fact that Xojo engineers can’t imagine a usecase should not become a reason for breaking existing code.

We did rely on the documentation and make use of it. Now Xojo makes all kind of radical changes to the syntax and with this is creating a whole lot of useless, unpaid work for those of us who have standard apps, which we want to maintain also in the future. Not all of us live from tailor-made software programming. Not all of us just start with the new framework on the next job.

I make use of SQLDate (vs SQLDateTime) in various places in my code, where I just need a date as a string in a clearly defined format. SQLDate comes in very handy, and skipping it in the new framework is just another hassle, after the string to text headache, etc.

Dim dat As String = "" Try dat = rs.Field("BookingDate").DateValue.SQLDate Catch err As UnsupportedFormatException End Try