Creating Xojo.Date from SQLDate and Timezone?

The new Xojo.Date class looks very interesting but I can’t see how to put an SQLDateTime formatted string in and set its timezone.

It seems I need to completely parse the SQLDateTime myself and construct a XojoDate from all the little pieces including the Timezone. Is there a better way to initialize a XojoDate from an SQLDateTime string and a Timezone (just need it to be GMT=0)

Thanks, Joe

Use a Nil locale to parse the date and time, but you will need to parse the zone yourself. It isn’t very pleasant.

Run the string through the following RegEx:

([0-9]{4})-([0-9]{2})-([0-9]{2}) ([0-9]{2}):([0-9]{2}):([0-9]{2})

Substring 1 will be the year, 2 the month, etc. (use Val, not CDbl, since an SQLDateTime is not localized). And to get a GMT time zone, just use “new Xojo.Core.TimeZone(0)”.

  1. New framework does not have RegEx yet
  2. CDbl and Val are old framework
  3. You just did the easy part in a harder way, and ignored the fact that time zone was desired in favor of GMT.

Xojo.Core.Date has a FromText shared method that will parse the date and time for you, but will not include the time zone. This means you need to first use this to create a new Xojo.Core.Date from the Text, parse the time zone information yourself, then create another new date using the first’s SecondsFromGMT and a new time zone object. This is because Xojo.Core.Date is immutable.

The FromText and ToText methods really should include the time zone, since even SQLite supports it.

using xojo.core

Dim dateValue As Text = “2015-08-01 11:00”
Dim d As Date = Date.FromText(dateValue)

dim d1 as new Date( d.SecondsFrom1970, new TimeZone(0) )

Unfortunately, that changes the time along with the time zone. Using an interval isn’t working right either, but I’ve sent that to Greg to get his input.

And it still requires you to create two dates. I missed that Joe is not actually interested in parsing the zone, and instead is using an implied GMT. Even in this scenario we need a better way, but we REALLY need a better way to handle explicit time zones.

Use the other constructor
Using xojo.core

Dim dateValue As Text = “2015-08-01 11:00”
Dim d As Date = Date.FromText(dateValue)

dim d1 as new Date( d.year, d.month,, d.hour, d.minute, d.second, 0, new TimeZone(0) )

Dates being immutable when you have one the only way to get one based off it is to create another.
It’s a couple lines of code and safer than the old mutators on the old date where if you changed them in the wrong order you’d get surprising results

In my benchmarks the new date class is about 10x slower than the old one. It seems to do less since it’s immutable so I’d hoped it would be faster than the old version. I’m processing over a million timestamps from log files with SQL timestamps in GMT and I’d like to have them in a date class so I can easily convert them to a user selectable local time. It take over 40 seconds to create a million of the old dates and 10x that for the new dates. Using 2x new dates isn’t feasible.

Another issue is that date.FromText not only doesn’t parse the timezone, but is assumes the current local timezone!!! So running my app in one location may give a different result than running it in another even though both are using UTC based timestamps.

If FromText isn’t going to allow setting the timezone, at least it could default to something consistent like GMT.

My next strategy is to write my own date class and just store the GMTtotalseconds myself.

aTimestampString = MyDate.Timestamp(TzOffset)

I’d use a SharedProperty to hold one instance of the old date class that I only need to create once. And whenever I need a timestamp in the local timezone I could feed the singleton date class a GMTtotalseconds and a GMToffset and get a nice local SQLDateTime timestamp.


The Locale seemed associated with the format of the date strings and not the timezone offset. I’d think that a given locale could easily encompass multiple timezones. The reference to the ISO Locale doc didn’t include any timezone parameters that I saw. (Tons of other minutiae though. :slight_smile:

Why not just stick with the old Date class for now?

Learning to port to the new framework now may not be necessary, but it is smart. You don’t know what the future will hold, but the future of Xojo is the new framework. Easy is not a word I’d use to describe the porting process.

Attempting to do this stuff now also helps to highlight areas where the new framework is inadequate. The Date class is one of them. I wasn’t aware it was so much slower, but I was aware it is much less versatile. I have no problem with it being immutable, but we need better creation options if that is going to be the case.

Joe, file specific feature requests. Nothing will happen without them.