Description
Thread copied from Teams on 2022-04-04:
Dan:
In writing up the instructions for handling the new gist time paradigm, I ran into what I believe to be a problem with the TimeZone and TimeZoneStandard classes.
The current draft formal definition for TimeZone is "gist:GeoRegion and (gist:hasOffsetToUniversal some gist:Duration)". The definition for TimeZoneStandard is "gist:Specification and (gist:isBasedOn some gist:TimeZone)".
I believe we have these a bit backwards because I cannot figure out how to create meaningful instances of these.
Instead, I think that TimeZoneStandard should be "gist:Specification and (gist:timeOffset some xsd:duration)", and TimeZone should be "gist:GeoRegion and (gist:isAffectedBy some gist:TimeZoneStandard)".
This requires bringing back the gist:timeOffset property I had in my original proposal.
gist:timeOffset rdf:type owl:DatatypeProperty ;
rdfs:range xsd:duration .
Example usage
:_TimeZoneStandard_easternStandard gist:TimeZoneStandard ;
gist:timeOffset "-PT5H"^^xsd:duration .
:_TimeZoneStandard_easternDaylight gist:TimeZoneStandard ;
gist:timeOffset "-PT4H"^^xsd:duration .
:_TimeZone_usEastern a gist:GeoRegion ;
gist:usesTimeZoneStandard :_TimeZoneStandard_easternDaylight .
:_Event_x gist:plannedDateTime "2022-06-08T09:00:00"^^xsd:dateTime ;
gist:usesTimeZoneStandard :_TimeZoneStandard_easternDaylight .
Rebecca:
Given the definition of TimeZoneStandard as "The algorithm for getting from Greenwich Mean Time to local time, which includes the time zone offset and rules about daylight savings time," it seems to me that there are not two standards, eastern standard and eastern daylight. Rather, this is one standard that has rules for when it switches from daylight to standard and back.
The definition does call for a time zone offset, however, but given that different time zones switch from daylight to standard on different dates, is this possible? If it is, then I'm in favor of it.
I prefer the semantics of gist:isBasedOn to gist:isAffectedBy, which is not specific enough, but I agree that we have it backwards - the time zone is based on the time zone started rather than the other way around.
I have a somewhat different idea of how this should go - I think an event takes place in a time zone, and is only indirectly related to the time zone standard through the time zone. This gives us triples such as:
:_TimeZoneStandard_eastern a gist:TimeZoneStandard .
:_GeoRegion_usEasternTimeZone a gist:TimeZone ;
gist:isBasedOn :_TimeZoneStandard_eastern .
:_Event_x gist:plannedEndMinute "2022-06-08T09:00:00"^^xsd:datetime ;
gist:isInTimeZone :_GeoRegion_usEasternTimeZone .