Remodel times to use datatype properties rather than TimeInstant

[rjyounes]

Proposal by @mkumba. Documents attached.

gistTime-apptx.pptx
experimentsWithDateDatatypes.ttl.txt

[rjyounes]

Adding to July 2021 project in order to consider postponing release of 10.0.0 to include these changes.

[rjyounes]

See description of #470:

As currently constituted (v9.7), gist provides no way to assert a start or stop time directly. It all relies on the use of TimeInstant instances, which can be cumbersome, hard to mint in a standard fashion, and not always necessary.
We should provide a standard set of datatype properties with an xsd:dateTime range. Provisionally, this could be something like:

gist:atDateTime
     gist:occurAtDateTime
     gist:startAtDateTime
     gist:endAtDateTime
     gist:createAtDateTime
     gist:changeAtDateTime
     gist:lastModifyAtDateTime

If adopted, some class restrictions should be rewritten to include the use of these in addition to the TimeInstant-dependent properties.

[rjyounes]

In the scope of this proposal, consider all issues labeled topic: dates and times.

[rjyounes]

See Dave's slides attached to the description for the implementation details. A couple of predicate name changes:

• XHumanInstant predicates change to XMinute - e.g., actualStartHumanDateTime => actualStartMinute
• XSytemTime predicates change to XMicrosecond - e.g., actualStartSystemTime => actualStartMicrosecond

Also consider the new predicate names in version 10.0.0 - see issue #188 and PR #535 where relevant.

[uscholdm]

• XSytemTime predicates change to XMicrosecond - e.g., actualStartSystemTime => actualStartMillisecond

Which is it, microsecond or millisecond? I thought the latter.

[rjyounes]

Yeah, I wondered, but system time uses microseconds (I think - someone else should confirm or disconfirm). How about nanoseconds? :)

[uscholdm]

But you have both in the above example. Pick one.

[rjyounes]

I see. I've fixed it above.

[Jamie-SA]

The spec says this about seconds: "secondFrag is a numeral consisting of exactly two decimal digits, or two decimal digits, a decimal point, and one or more trailing digits"

That seems to say to me that it is neither microseconds or milliseconds. It is a fractional second to an arbitrary precision.

[rjyounes]

Then we need to call it "SystemTime" as Dave originally had it.

[Jamie-SA]

Do we have the final recommendation posted somewhere? Or a PR with the changes?
I'd like to start using the new terms on a project.

[mkumba]

Dan sent me an early draft, I switched the namespace to gist and corrected a couple of the more egregious errors. I changed dateTimeStatmp to dateeTime, as the spec says there are two differences, one dateTime is one of the primitives (therefore I’m hoping more widespread use by query engines) and the only difference is that Stamp requires a timezone offset On Dec 8, 2021, at 10:15 AM, Jamie-SA ***@***.******@***.***>> wrote: Do we have the final recommendation posted somewhere? Or a PR with the changes? I'd like to start using the new terms on a project. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#499 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAGJPWOX2IR523OIP6FF43UP6HEZANCNFSM47QXB2YA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[uscholdm]

My recollection is that Dave presented a suggested a major reworking of how we do dates and times. I remember thinking it was very workable and I don't recall a lot of push back. But I also do not recall any overt consensus to move forward with the idea. So I'd be a bit surprised if someone went ahead and did the work with a PR awaiting review.

[rjyounes]

@uscholdm Looks like you're correct. We need to discuss this further, once we've conquered countries and governments. @DanCarey404 If you agree with this, you could hold off on submitting a PR.

[Jamie-SA]

Hmmm, I thought we had reviewed this and were getting close to approving the set of dataproperties. There were a few small concerns still left. I hope we didn't lose ground by putting it off instead of just completing it when it was fresh on people's minds.

[rjyounes]

Assigning Mark to perform any cleanup on Dave's time modifications and submit a PR.