Opened 8 years ago

Closed 8 years ago

#21 closed defect (fixed)

Semantics of year fields, and clarifying onset

Reported by: tim@… Owned by: cyrus@…
Priority: major Milestone:
Component: service Version:
Severity: Active WG Document Keywords:
Cc:

Description

In Asia/Singapore?, there is a transition from 1982-01-01T00:00+07:30 to 1982-01-01T00:30+08:00.
https://github.com/eggert/tz/blob/3962fae49c5294f0ce79353632a93b5a1db206f6/asia#L2468
However, this transition can also be said to have taken place at 1981-12-31T16:30Z. So, for the purposes of data truncation and start/end fields in expansion requests, in which year is this transition considered to have happened? 1981 or 1982?

In other words, while it's fairly clear to me that the year fields refer to 01-01T00:00 as the reference points for each boundary (although maybe that should be made clearer in the draft), is that to be interpreted as local or UTC? If the former, which local?

Currently, this demo includes it in 1982...
https://demo.calendarserver.org:8443/stdtimezones?action=expand&tzid=Asia/Singapore&start=1980&end=1983
{

"dtstamp":"2014-06-09T19:47:04Z",
"observances":[

{

"name":"SGT",
"onset":"1980-01-01T00:00:00",
"utc-offset-to":27000,
"utc-offset-from":27000

},
{

"name":"SGT",
"onset":"1982-01-01T00:00:00",
"utc-offset-to":28800,
"utc-offset-from":27000

}

]

}

...but not in 1981...
https://demo.calendarserver.org:8443/stdtimezones?action=expand&tzid=Asia/Singapore&start=1980&end=1982
{

"dtstamp":"2014-06-09T19:47:04Z",
"observances":[

{

"name":"(SGT)",
"onset":"1980-01-01T00:00:00",
"utc-offset-to":27000,
"utc-offset-from":27000

}

]

}

...so that would imply that this demo is currently treating it as local.

I can see either practice being valid, but I think it might be wise to specify one (preferably UTC) in the protocol. Additionally, I think it would help, even just with readability, to have either offset information specified directly in the onset field, or the onset field specified in UTC.

Alternatively, we could require that implementations include the full UTC timestamps used for cutoffs within their responses, to ensure that clients know for exactly what set of timestamps they have received complete information. For a server using 01-01T00:00 UTC as cutoffs, this could look something like:

{

"dtstamp": "2014-06-09T19:47:04Z",
"observances": [

{

"name": "SGT",
"onset": "1980-01-01T07:30:00+0730",
"utc-offset-from": 27000,
"utc-offset-to": 27000

},
{

"name": "SGT",
"onset": "1982-01-01T00:00:00+0730",
"utc-offset-from": 27000,
"utc-offset-to": 28800

}

],
"observance-bounds": [

"1980-01-01T07:30:00+0730",
"1982-01-01T08:00:00+0800"

]

}

I think the extra data required in this version is perhaps a bit much, so I would propose simply specifying the semantics of these year fields in the protocol.

Change History (2)

comment:1 Changed 8 years ago by lear@…

  • Component set to service
  • Severity changed from Candidate WG Document to Active WG Document

-01 is said to address this ticket through use of UTC. Working group participants are invited to review this change to see that it indeed addresses this issue.

comment:2 Changed 8 years ago by mglt.ietf@…

  • Resolution set to fixed
  • Status changed from new to closed

Text of section 6.4 seems to have reached consensus. http://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-6.4

start=<date-time>: REQUIRED, but MUST occur only once. Specifies

the inclusive UTC date-time value for the start of the period
of interest.

end=<date-time>: OPTIONAL, but MUST occur only once. If present,

specifies the exclusive UTC date-time value for the end of the
period of interest. If "end" is omitted, the value is the
"start" parameter value plus 10 years. Note that this is the
exclusive end value - i.e., it represents the date just after
the range of interest. e.g., if a client wants the expanded
date just for the year 2014, it would use a start value of
"2014-01-01T00:00:00Z" and an end value of
"2015-01-01T00:00:00Z". An error occurs if the end value is
less than or equal to the start value.

Note: See TracTickets for help on using tickets.