I ran across an issue with Xojo.Core.Date that I talked about on the forums https://forum.xojo.com/18549-xojo-core-date-question.

The issue is that the new Date class does not have SQLDateTime.  Well, technically it does with a generic ToText function.  However, there is no way to get just the SQLDate portion without having to write your own method.

The ToText method has a LOT of power to do and it is considerably more powerful than the old Date class.  The ability to work with Locale is very cool and should simplify some things.  However, I have some issues with the ‘replacement’ for SQLDateTime.

First, SQLDateTime is very explicit in what it does.  ToText (with no parameters) doesn’t tell me jack and the fact that I missed it in the documentation tells me the name absolutely 100% fails the ‘name explicitly tells you what it does’ test.

Second, there’s no option to just get the Date in SQL format.  Sure, you can create your own method to get that but that’s one more thing to create, test, and maintain.  There are times when you need just the SQLdate portion.  It doesn’t matter why we need it – we need it.

The new Date class is full of wonderful things.  However, removing functionality that many of us use every day should be avoided.  I think this is one of those times where the Xojo engineers got too clever in the new framework.  I’d much rather have the SQLDateTime and SQLDate methods back.  They are much more explicit than ToText.  If you agree, you can sign on to <feedback://showreport?report_id=37521>

Of course, like with the Numeric.FromText methods, I’m willing to be convinced that the Date.ToText method to get SQLDateTime is better.  What say you?



Later I realized that we could accomplish everything by adding the SQL option to the DateFormat and Locale enumerations.  Then the code would be something like this:

dim d as Xojo.Core.Date = Xojo.Core.Date.Now

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

That would solve all of the issues, no?  They get to keep ToText and we get the ability to format the date in whatever form we want.  Then there is no ToText without Parameters.

10 thoughts on “Xojo.Core.Date

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

    While it may do the job, that is an awful lot of code and a lot less discoverable than
    Dim t as text = d.SQLDateTime
    Dim t as text = d.SQLDate

    BTW I think few people learning to code would expect SQLDateTime back for ToText with parameters as such people would not have been exposed to SQL…

    They would expect it in local time in the default format set for the OS.

    – Karen

    • Well, I didn’t say it was perfect but Xojo doesn’t have to tack on additional methods. They simply need to extend the enums they already have.

      • I do rely on SQLDateTime in my apps. I do understand that ToText may well be a better solution going forward, but it is a real bind to re-code existing apps which are functioning well. Backwards compatibility is important, and as Bob suggests, a ToText extension that returns the same string as .SQLDate / Time would be a workable solution.

  2. I finished an hour long video on Xojo.Core.Date today. I’m starting to think the ‘wall of code’ issue is real and while it’s not that bad on a large screen, it *is* an annoyance. I am going to look at ways to make it better.

    Does the new ‘using’ keyword make this any better?

  3. I’ve not used “USING” yet because i need my code to be backward compatible as I need to support some 10.6 machines, but it looks like it certainly could depending on how you structure/organize your code.

    If you add a using clause to module the scope is the whole module (and it’s contained classes I assume).

    You can also add it a class so the scope is the whole class. You can also use it in code the scope is the code block.

    I assume you can have more than one at each level…

  4. Are the newest Xojo Data Types documented anywhere? I looked at the PDFs and the Language Reference, but cannot seem to find good information on Locale (for example).

  5. Thanks Bob! I saw that there is a feedback request to have a combined documentation set available. Definitely some room for improvement on the documentation front. I’ll check out the new classes. Appreciate all your efforts in the Xojo community.

    • They are in kind of a weird spot. iOS is the only target the REQUIRES the new framework but yet, eventually, it will come to all targets.

      I dunno if they plan on converting everything over to this new documentation system or not. I’m used it enough to know that it’s a little easier to navigate than the existing one. I don’t think it’s as easy to search so I’m kind of on the fence as to whether it’s ‘better’ or just ‘different’.

Comments are closed.