Xojo.Core.Date and timezones

General
1

I’m getting a bit confused about timezones and the modern framework Date class.

I am trying to store the modification date of a file as UNIX seconds in a local SQLite database and then compare that value with the current time. What seems to be happening is that even if I create a file on disk and then immediately read back it’s modification date and convert to UNIX seconds, it is 1 hour out of alignment with a call to Date.Now. This is on the same laptop running Windows 10. As far as I can tell this must be some sort of British Summer Time thing (which is GMT+1 hour). What I don’t understand is why the dates are not virtually the same given the file is created on the same machine that is calling Date.Now.

2

How do you store it? As a REAL and how do you read it from the database back? As a Double?

Xojo.Core.Date.SecondsFrom1970 is as Double if you store that you must read it back like that with the same Xojo.Core.Timezone

Edit; your best bet is using the new framework here. I’ve had some oddities with the old framework and date storage.

3

[quote=340196:@Derk Jochems]How do you store it? As a REAL and how do you read it from the database back? As a Double?

Xojo.Core.Date.SecondsFrom1970 is as Double if you store that you must read it back like that with the same Xojo.Core.Timezone

Edit; your best bet is using the new framework here. I’ve had some oddities with the old framework and date storage.[/quote]
I disagree, the old date class has had much longer to work the kinks out of and is generally easier to work with. The new one has potential, but needs some love. For example, Xojo.Core.Date.FromText really should do one (or both) of two things: 1) respect the offset if provided in the sql timestamp and/or 2) allow a time zone to be passed to FromText.

Because right now, if I’m reading a SQL that I know to be UTC, here’s the old framework version:

Dim D As New Date D.GMTOffset = 0 D.SQLDateTime = StringValue

And converting it to local time is pretty simple too:

Dim D As New Date Dim LocalOffset As Double = D.GMTOffset D.GMTOffset = 0 D.SQLDateTime = StringValue D.GMTOffset = LocalOffset

And with the new framework, it gets pretty bad.

Dim TempDate As Xojo.Core.Date = Xojo.Core.Date.FromText(TextValue) Dim D As New Xojo.Core.Date(TempDate.SecondsFrom1970 + TempDate.TimeZone.SecondsFromGMT, New Xojo.Core.TimeZone("UTC"))

And Localized:

Dim TempDate As Xojo.Core.Date = Xojo.Core.Date.FromText(TextValue) TempDate = New Xojo.Core.Date(TempDate.SecondsFrom1970 + TempDate.TimeZone.SecondsFromGMT, New Xojo.Core.TimeZone("UTC")) Dim D As New Xojo.Core.Date(TempDate.SecondsFrom1970)

3 objects. But it gets worse. TimeZone.SecondsFromGMT isn’t always correct. Found this the hard way on Windows, likely to be a DST issue. This is what you’re seeing @Garry Pettet! So what you really need to do is

Dim Now As New Date Dim TempDate As Xojo.Core.Date = Xojo.Core.Date.FromText(TextValue) Dim D As New Xojo.Core.Date(TempDate.SecondsFrom1970 + (Now.GMTOffset * 3600), New Xojo.Core.TimeZone("UTC"))

So you end up having to go back to the classic date for reliability anyway. The new framework version requires technically fewer lines, but is more complicated. And it could be so much nicer:

Dim D As New Xojo.Core.Date(TextValue, New Xojo.Core.TimeZone("UTC"))

Because why does text parsing need to be a shared method anyway? If FromText is so good, why don’t we have Xojo.Core.Date.FromSecondsSince1970? Why does that get to be a constructor?

The classic date class has its problems. Some pretty significant ones. But jeez, its replacement is actually worse in most respects.