Guy Ross
posted this
01 August 2023
- Last edited 01 August 2023
Hi Clive,
Thanks for that. I believe in both cases the sample is compliant. I also agree that yes, the specification is sometimes lacking or counterintuitive, and could be improved.
There appears to be two issues here.
1. Identifying daylight savings, and
2. Identifying the start/end of a period.
For the first:
This is consistent with other longstanding interchange formats.
The specification refers to the code:
Refer to clause 15.36 of Part 15 of the Code. If information is NZDT adjusted, the field may be left BLANK, otherwise if it is not adjusted, ‘NZST’ must be used.
Which says:
(3) A daylight savings adjustment must be made by using the “trading period run on technique”, which requires that daylight saving adjustment periods are allocated as consecutive trading periods within the relevant day, in the sequence that they occur.
(4) If no adjustment is made in accordance with subclause (3) to information exchanged between reconciliation participants that contains trading period specific data, the code “NZST” must be used within the data transfer file.
My plain English interpretation of this, is that the default option is to use “clock” time (ie NZST in winter and NZDT for summer). Listed, in order, when going into summer time. In this case, the time zone may optionally be left blank.
Otherwise, if not using NZDT during summer time, then it must be identified explicitly as “NZST”
You’re right though, it certainly wouldn’t hurt to make the NZST/NZDT values mandatory, and we’ll look at encouraging that the next time the SDFG gets together.
For the second:
Yes. Most systems would agree that a period starts at hh:00:00, although that does just shift the interpretation issue to the other end of the period. (Is it hh:30:00? hh:29:59? hh:29:59.999?).
From the specification:
5.1 If the interval of a consumption record is less than one whole day, the Time part of the DateTime formatted value must reflect the appropriate hours, minutes and seconds of the record (eg a half hour trading period record could have a start date/time of “01/03/2016 00:30:01” and an end date/time of “01/03/2016 01:00:00”).
There’s elements of common sense, and, standard datetime interpretation issues at play here. Regardless of interpretation, 30 minutes still equals 30 minutes.
Again, some clearer standards, and references to things like inclusive start/exclusive end times will be encouraged next time the EIEP13 formats go out for consultation.
I’ve edited the sample to be clearer.
