Xojo Blog: Better Dates

Geof posted about the virtues if new framework date class… arguing that it’s better to use despite being a bit more work because of how it handles time zones… and arguing once the new framework becomes standard it’s only one more line of code (you can get rid of the Using Clause) … In fact it could be one less than that by getting rid of the Dim of the DateInterval object

Dim d As New Date(2017,11,5,TimeZone.Current)
d = d + New  DateInterval(0, 0, 0, 3)

Compared to:

Dim d As New Date (2017,11,5) d.Hour = d.Hour + 3 MsgBox(Str(d))

But which is more accessible to the beginner or the non professional that just wants to create a solution quickly to a very specific need on their job? Which is more generally intuitive?

I’m not arguing against the need to deal with time zone or saying this particular thing is a big issue… but the overall nitpicking and formalisms make the new framework a lot less fun to use to use and less approachable than teh old. One needs an overall high level of computer science (not sure that is the right term) background knowledge to do simple things compared to the old framework…

Because of it’s rigorously formal nitpicking, the verbosity goes beyond namespaces when one writes code… and using it , at least for me, feels more mechanical than creative when compared to working with the old framework… and takes longer to accomplish the same thing (though familiarity could be a factor there)

I know more than few consider that a virtue , but if the new framework had been in place in RBV3 (when I came in), I wonder if I would have stayed with it.

  • karen

Personally, I think the example Geoff gave is actually WORSE! It’s worse because the DateInterval constructor has 4 parameters and you can’t tell jack from just looking at the code. I mean, I can guess what they are (year, month, day, hour) but it’s not as readily apparent as the second example which has zero guessing (even though it could be incorrect).

To be very explicit to even novice Xojo developers I would do this:

dim di as new DateInterval di.hours = 3
Absolutely zero issues with what DateInterval is. To me it’s a readability issue even if it’s not as compact.

I think there are a lot of good things in the new framework but this isn’t one of them, in my opinion. The new date class is stricter and thus safer in many aspects, but I wouldn’t call it easier to understand depending on how your write it. To make it easier to understand you do have to write more lines of code. Again, my opinion.

I think some of these issues will start to drop away as the new framework gets used more but I think your points are valid, Karen.

@Bob Keeney perhaps xojo needs a cursor position hint in a status bar or so.

Let’s say your cursor is at the “:” in the following code

Dim di As New DateInterval(0, : 

the statusbar (below the code editor) could show:

Bold will be the current parameter that is being edited. rest is normal text.

That would be a great addition for ALL Xojo code hints!


How would this work when the constructor is overloaded? The IDE may not be able to guess which constructor you are intending on using until you’ve added a few parameters.

That (overloads) is why I miss the tips window, for those that remember it…

One solution with this UI (besides the IDE guessing which overlaid to display first) is using up/down arrows at the start of the bar to be able to cycle though the overloads. No overloads then Up-Down arrow.

  • Karen

Karen I’m a beginner and for my program I just need dates and not time. I’m using SQLDate with SQLite. Pretty easy. I don’t see SQLDate with Xojo.Core.Date. I guess I’ll have to learn how to deal with that in the future.

From what I read, sometime in the future there will be no Date and Xojo.Core.Date, and only the new one. So I’ll find soon how hard is for me to change my program.

Let the xojo devs come up with that.

Perhaps looking at the current cursor data type.

sounds a lot like this request

well it’s a very old case …

It is - because its NOT quite as simple to implement as you guys might thing it is
It was requested by an ex-engineer who had tried to do make the IDE do this AFAIK

I’ve investigated it periodically and its quite difficult to do and would probably make autocomplete slower

What going to happen with my extensive use of d.SQLDate in my code when Date Classic is actually removed? Will the new framework somehow accommodate such code?

Alternatively, will I just be able to roll my own Date class extension SQLDate when Date Classic disappears, and just leave d.SQLDate entries alone?

I don’t think that will be an issue for quite some time.
Additionally, you could file a feature request for a SQLDate method on the new date class.

[quote=357680:@Tim Parnell]I don’t think that will be an issue for quite some time.
Additionally, you could file a feature request for a SQLDate method on the new date class.[/quote]
Looks like this has been requested: Feedback 37521.

A variation of the 62 case is in the VBA editor since I do VBA (2000 or so). This really makes a difference for functions that have more than 3 or more parameters. A pity.

FWIW, I did write about this about 3 years ago. https://www.bkeeneybriefs.com/2014/12/xojo-core-date/

And it turns out there IS a relatively easy way to get SQLDate, SQLTime, and SQLDateTime using the ToText FormatStyle options.

[code]dim d as Xojo.Core.Date = Xojo.Core.Date.Now

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

I will grant you that it’s not very discoverable and not as simple as the old framework methods. But given then information it would be easy enough to create your own extends methods for the Xojo.Core.Date class.

For FormatStyles.SQL is no longer available. Not sure when it left. However, according the documentation:

So by putting in a nil Local it returns SQLDateTime.

However, the fact that we’re still talking about it says Xojo.Core.Date isn’t as user friendly as it should be.

I did another blog post on this: https://www.bkeeneybriefs.com/2017/11/xojo-core-date-revisited/