Xojo.Core.Date Revisited

Geoff Perlman wrote a blog post https://blog.xojo.com/2017/11/04/get-better-dates-with-the-new-xojo-framework/ on how the new Xojo.Core.Date gives you a better date.  Better in that it does a superior job of handling timezones.

I will concede the point that the new Xojo Date class is better at timezones.  Timezones are icky and there are various areas of the world where they observe only partial increments of timezones.  The existing, global framework simply can’t handle those geographical timezones properly.  In addition to that, the global framework can get it wrong.  So the new framework is inherently better with timezones:  got it.

Where Geoff’s blog post goes sour, in my opinion, is when he talks about how the new Xojo Date and DateInterval classes cause more code but then goes on to show how it can made shorter.  I think his shortened example is indicative of the overall problem with new framework.

He starts with this example (note I am not implementing the Using keyword on purpose):

Dim d As New Xojo.Core.Date (2017, 11, 5, Xojo.Core.TimeZone.Current)

Dim di As New Xojo.Core.DateInterval

di.Hours = 3

d = d + di


The results is a message dialog displaying:  2017-11-05 02:00:00.  This is what the old Date.SQLDateTime method returned and what many developers need for database SQL operations.

He then goes on to show that this code can be reduced to:

Dim d As New Date (2017,11,5,TimeZone.Current)

Dim di As New DateInterval(0, 0, 0, 3)

d = d + di


Sure, it’s reduced, but now we’re passing parameters into the DateInterval constructor that we have to just know what they are.  Granted, it’s not hard to figure it out but when I’m reading code I don’t want to have to ‘figure it out’.  Whereas the first example was pretty explicit (add three hours) now I have to parse the number of parameters to figure out it’s three hours and not three days or three months or three seconds.  If when writing code I accidentally leave out a 0 it wouldn’t be immediately obvious that I’m not adding three hours but three days.  Ambiguity is never a good thing and I can’t tell you how many errors I’ve found in methods that have multiple parameters with default values because someone (usually me) missed a parameter.

I’d also argue that the documentation for Xojo.Core.Date is using, at worst, wrong example code or, at best incomplete documentation.  Using the variations of ToText results in some counterintuitive results.  If you use Xojo.core.Locale.Current (as all of the Xojo examples do), you get results based on YOUR system settings.  Really what you should be using is Xojo.core.Locale.Raw.  Below is a table that shows the differences for the following line of code when run on my macOS machine:

Dim s1 As String = d.ToText(Xojo.core.Locale.X, Xojo.core.Date.FormatStyles.Full, Xojo.core.Date.FormatStyles.None)

X = Xojo.core.Locale.CurrentXojo.core.Date.FormatStyles.Full 2017-11-05
Xojo.Core.Locale.Current Results
Format Result
Xojo.core.Date.FormatStyles.Long Sunday, November 5, 2017
Xojo.core.Date.FormatStyles.Medium Nov 5, 2017
Xojo.core.Date.FormatStyles.Short 11/5/2017
Xojo.Core.Locale.Raw Results
Format Result
Xojo.core.Date.FormatStyles.Long 2017-11-05
Xojo.core.Date.FormatStyles.Medium 2017-11-05
Xojo.core.Date.FormatStyles.Short 2017-11-05
Xojo.core.Date.FormatStyles.None 2017-11-05

So given these results it’s impossible in the new framework to get just SQLDate as the FormatStyles.None is ignored.  <feedback://showreport?report_id=50242>  Until this fixed, to do this on your own you would have to split the Text on the space and use the first half of it.

The only reason why anyone should ever use Xojo.Core.Locale.Current is to display the date/time to a user.  Xojo.Core.Locale.Raw should be used for everything else.  The distinction between these variations is confusing even to experienced Xojo users so I can only imagine the frustration from newcomers.

Ultimately, the New Xojo framework is not very discoverable and this leads to frustration.  While writing this article, to figure out the parameters in the Xojo.Core.Date.ToText function, I had to look in the freaking documentation.  Yes, there is the tips area but it’s not very helpful while you’re typing.  To see what the tip is you have to stop and hover your mouse over the method.  And that only works if it’s not an overloaded method.

This leads to some users complaining that Xojo isn’t as much ‘fun’.  At first I pooh-poohed the idea but the more I think about it, it’s true.  The new Xojo framework is verbose and hard to discover and therefore not as much fun.  I work in this language every day and while calling it ‘fun’ might be a bit of a stretch I can tell you that using the new framework isn’t fun.  The two client iOS projects I’ve done in Xojo have been painful for a number of reasons and not being fun is a valid but minor point.  I don’t find the documentation to be nearly as easy to read and discover related topics, and frankly the new framework seems to make things harder than necessary.  Certainly there is a ‘this is the way I like it’ factor you’d get from someone with nearly twenty years using a language but I do feel that the new framework is needlessly nit-picky.

My first blog post https://www.bkeeneybriefs.com/2014/12/xojo-core-date/ on the Xojo.Core.Date class was in December of 2014.  It’s nearly three years later and we’re still dealing with bugs and idiosyncrasies and it’s not widely used despite clearly being ‘better’.  It’s no wonder why people don’t really want to use the new framework and I wonder if any parts of the IDE are using the new framework.

What are your thoughts on the Xojo framework?

20 thoughts on “Xojo.Core.Date Revisited

  1. I was the one who made the ” no fun” comments from my first exposure to the new framework.

    What that means to me is that the old framework does not get in the way of the creative process … it does not interrupt the the flow with nit-picking like the new framework does. Teh new feels like slogging though the mud by comparison.

    • I believe this is simply a result of familiarity. It catches me too sometimes because I’m using Strings one minute and Text the next.
      You are familiar with the classic framework while the new framework, is, well, new. Once you are familiar with the new framework the feeling of “slogging” will pass. I’m quite confident of that. I’m also confident that new users will not have that feeling because they will be learning the new framework from the get-go.

      • I’ve done several largish iOS projects in the past 12 months. That’s more than long enough to get past the ‘slogging’ stage. There is something inherently ‘harder’ about the new framework that the old framework doesn’t have.

  2. Code written with the new date class can be written without the constructor making it quite readable. While it’s true this might require an extra line or two, the result is that your app doesn’t potentially end up with hard to find bugs that only appear at runtime when your end user encounters them. I think the trade off is well worth it.

    As for discoverability, I think you hit on the most important point and that is one of familiarity. The more you use the new framework, the more familiar it will be. However, more importantly, we have taken great care to make the new framework extremely self-consistent which makes it even more discoverable than the classic one. Once you know how to use a particular class, you’ll find that similar classes have identical or nearly identical APIs.

    The namespaces can make it feel less friendly but those are really only transitionary. Eventually they will not be required. Right now we are in the middle of that transition, which results in using both the old and the new APIs. That can be confusing. Eventually you will be using the new APIs exclusively and that potential confusion will pass.

    The changes we are making are a trade-off for users already familiar with the current APIs. On one hand, they are new which means learning something new to do what you already know how to do. On the other, you’ll have fewer bugs in your code and in the long run, a far easier time learning new APIs or remembering ones you haven’t used in a while.

    It can be an uneasy feeling to find yourself unfamiliar in a place where all should be quite familiar. This too shall pass.

    • Until it’s the only way to do desktop or web projects we will always have this debate on how it feels to us in comparison. But I can say that 3 years since introduction there are still bugs/nuances being found in Dates, Text, and Auto (to name a few I know about).

      I’ve said this before, but I’ll say it again, you guys write ONE commercial product and you rarely have to start from scratch on other big projects. So yes, you use your product to create your (really large) product but it’s one product not the dozens a year that someone like myself does. And because you don’t see the same breadth of issues there are parts of Xojo that don’t feel complete (reporting and database editor to name a few) or completely underwhelming from a developers perspective. Not to mention missing controls that should be part of the product when someone uses it for something other than example projects (date/calendar and grid to name a few).

      • We have a few large public applications (Xojo and Feedback), a large internal application that does all of our customer and order tracking and lots of smaller applications that perform a variety of tasks from sales automation to build automation and more. Many of these applications connect to databases. In short, we use Xojo A LOT. We may not use it exactly the way you do but that’s not unusual. We have customers that use Xojo in many different ways. Some uses databases a lot while others never do.

        We see many of the issues you and other users see. However, just like you, we have to prioritize. We would love to implement every feature or resolve every bug but that’s unrealistic even for software companies many times our size. So we prioritize and work from there, just like everyone else. Hopefully we prioritize correctly and make most people happy in the process. When we don’t, Xojo users will let us know. 🙂

  3. Geoff,

    I can assure you, at least for me, it’s NOT the namespaces… it’s about how strict/nit picking it is compared to the old framework. That what I mean by getting in teh way of teh creative process as compared to the old framework…

    Yes familiarity is part of it… but I remember how I felt when first learning the old framework… and I did not feel so … nit picked. (not sure what word to use). Teh new framework feels like it has the soul of an accountant!

    And again it’s not the namespaces… and I know I am not the only one who feels this way.

    • Yeah, I’m actually okay with the namespaces, for now. To me I absolutely do not want to use Using because the more verbose style lets me switch mentally without too much trouble (though it does tend to mean the ‘wall of code’ that some have complained about).

    • Agreed. It’s not the namespaces. We’re familiar with namespaces when we create and use modules. The new framework just feels geekier than the friendly old framework. Sure we can all create our own helper methods, but why not have those common helpers methods built into the product?

  4. “Yes, there is the tips area but it’s not very helpful while you’re typing. To see what the tip is you have to stop and hover your mouse over the method. And that only works if it’s not an overloaded method.”

    Maybe they should have read my “Simple Help” article in xDev … 😉

    I come from a HyperCard background, and I remember I decided against the “obvious” choice Runtime Revolution because it was way to verbose and lacked the simple elegance of REALbasic. The new Xojo framework reminds me of Runtime Revolution … I don’t like it at all.

  5. I personally very much prefer the DateInterval class over date manipulations with the classic Date class. That being said the Date class is something we use so often that keeping the API similar would have been desirable. My muscle memory gets annoyed when it’s incorrect.

  6. Cross-posting from Phillip’s blog:

    As a third-party developer, the new framework is a non-starter for me. My customers use varying versions of Xojo because the community consists largely of solo developers whose wallets may be thin. I can’t commit to the new framework in any meaningful way. I tried. I started using .ToText, the new Dictionary class, the new Date class, and immediately after release I was flooded with support tickets about being unable to use the new version due to these added features.

    For me, I either stick with Classic and support all customers regardless of their income, or move to the new framework and lose customers. If they really want to push the new framework, for me to be on-board, I’d like to see a plugin for older versions of Xojo that contains the new framework. Hell, shove the whole new framework in a plugin for old and new versions. Why not?

    As far as the compatibility of the new framework, major thumbs down. I despise working with the new framework for iOS. I really do. If I’m in Xojo, I want to be able to code once and deploy anywhere. That’s what the marketing said.

    I love Xojo, and I’m a big fan of the people behind the scenes, but the new framework is a swing and miss in my book.

    • In Shorts we *were* using the new Dictionary class too. And, like you, ended up stripping it from the product.

      The bottom line is 3rd party developers, and our customers, require the classic framework until the time when the new framework is the ONLY option.

      While I’m not ready to call the new framework a bust yet, I do think it’s lacking in fundamental usefulness.

      • Another facet to the issue is that, for the foreseeable future, the new framework won’t be the only option. We’ll see customers who continue to stick with old versions of Xojo (and Real Studio, in some cases) due to other concerns.

        I like that they’re advancing the language. I want to see a more modern experience. I just have a lot of concerns about the push forward with the new framework that A.) doesn’t appear to be ready to replace the classic framework, and B.) alienates customers who either can’t afford to renew right now or can’t upgrade due to issues.

        It’s a balancing act for sure, for both them and us.

Comments are closed.