Changeset dates and timestamps

Learn about the timestamp parameter and how to use it effectively.

Format

Changeset API timestamps are provided in UTC time by default. We use this format to avoid any issues associated with daylight savings. You can define your timestamps using alternative formats but will need to make sure they are correctly URL encoded.

The default timestamp is a combined date and time format which is accurate to the millisecond. The letter T is used as a delimiter preceding the time element.

  • Date is specified as YYYY-MM-DD
  • Time is specified as hh:mm:ss.ssssss
  • For example, 2015-05-15T04:25:25.334974

Timestamp event

The timestamp is the time at which the changeset revision was published on LDS (in UTC time). For example, property and boundary data is extracted from Landonline for processing at the close of business on Friday. The timestamp is made on either Saturday or Sunday, the day it was published to LDS.

FROM and TO parameters

The Changeset API includes the FROM and TO timestamp parameters to specify the range of time to return changes between.

Each changeset for a dataset is published as a numbered revision with a unique timestamp. Revisions are sequential where the FROM timestamp of a new revision matches the TO timestamp of the previous revision. The letter Z is a suffix meaning a UTC offset of 00:00.

Revision

From

To

366

2018-09-01T07:35:20.049485Z

2018-09-08T10:34:27.542927Z

365

2018-08-25T07:33:06.274671Z

2018-09-01T07:35:20.049485Z

Top tips for timestamps

  • The FROM timestamp is exclusive, so a request where the FROM timestamp is identical to the revision’s timestamp will not get data for that revision.
  • The TO timestamp is inclusive, so a request for data where the TO timestamp is identical to the revision’s timestamp will get data for that revision.
  • Timestamps are accurate to the millisecond. If only '2018-09-01' is specified, LDS will interpret it as 2018-09-01 0:00.00000 (midnight). To allow for delays or longer data processing times, it is advisable to add a day’s buffer into your changeset request to ensure all changed data is fetched.
  • A request where the FROM timestamp is set prior the first revision date and TO timestamp to the required revision date will get the data as at the selected revision.

This example makes a WFS 2.0.0 GetFeature request for the NZ Primary Parcels layer changeset from 15 August 2000 to 4 August 2018. As the FROM time is prior to the start of changeset, this request actually retrieves the primary parcel data as at 4 August 2018.

https://data.linz.govt.nz/services;key=YOUR_API_KEY/wfs?SERVICE=WFS &VERSION=2.0.0 &REQUEST=GetFeature &typeName=layer-50772-changeset &viewparams=from:2000-08-15;to:2018-08-04