Opened 8 years ago

Closed 8 years ago

#32 closed defect (fixed)

managing historical data

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

Description

If I provide archived data that has been created using the
current set of timezone data and in ten years time someone is accessing
that data they need to be able to process the data using the SAME view
of the timezone data. This may well have changed so that the current
data set is different, and while 'changed_since' can say that there has
been a change, it provides no basis on which to access just what has
changed in the intervening 10 years. The user needs to be able to ask
for the correct view from ten years ago as they did not have that data
as a starting point with which to use the current data.

If we haven't built the handling of this into the standard now, then in
ten years time the historic data is unusable. Or we need a different
source of tz data that can be relied on in the future for that
application.

Change History (3)

comment:1 Changed 8 years ago by lear@…

Looking for elaboration from Lester on this point, as well as whether it needs into a base spec.

comment:2 Changed 8 years ago by lear@…

Proposal made on December 17 by Cyrus that handles use cases discussed on list.
Next steps: some examples to list.
Examples may be included in an appendix.
Chairs will seek agreement on proposal by end of first week of January.
This does not handle the historical data case. That will be handled in the tz/version request.
Cyrus may put out a new draft to show how this will read in context.

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

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

historical data are managed with a combination of ETag and opaque token.

Note: See TracTickets for help on using tickets.