Date and Time representations

[karel-debrabandere-bosa-fgov-be]

The documentation describes the way to encode date and time data in the xml as follows:

<cbc:IssueDate>2019-11-26+01:00</cbc:IssueDate>
<cbc:IssueTime>13:38:54+01:00</cbc:IssueTime>

The SDK encodes date and time fields separately (in the visual model, the conceptual model and the xml document).

There is an issue with calculating the timezone offset:

• The only way to correctly determine the timezone offset on the dates that a DST transition takes place, is to take into account both date and time. For example: on Oktober 30th at 02:30, the timezone offset in belgium is GMT+0200, but at 03:30 it is GMT+0100.
• The SDK does not allow us to robustly link the date and time fields.

[YvesJo]

Yes both, date and time have to be considered jointly to end-up with consistent information and both should share the same time-zone. Segregation of date and time is imposed by the UBL standard.

[karel-debrabandere-bosa-fgov-be]

I don't understand.

Yes both, date and time have to be considered jointly to end-up with consistent information and both should share the same time-zone.

==> we have to link the two fields somehow.

Segregation of date and time is imposed by the UBL standard.

==> we cannot link the fields

Personally, I would have expected these two separate fields to instead be a single field of type datetime.

[YvesJo]

For some concepts like deadlines it is not recommended to consider date and time separately and they should be considered as a whole.
UBL defines two separate elements, one for the date, and another for the time and we must comply with the standard, so 2 fields had to be defined.
The easiest way to prevent unexpected issues for deadlines is to make sure both (date and time) are expressed using a same time-zone.
While there is no freedom for the XML mark-up, the UI may be designed in a way that may help users.

[JannickFaber]

If date and time should be considered as a whole, it would help if there was a constraint inside fields.json which ensures that.
e.g. BT-131(d)-Lot should be invalid if it has a value while BT-131(t)-Lot is empty. If we look from the time-fields point of view it becomes even more important. It is currently valid to have a value at BT-131(t)-Lot and have no value at BT-131(d)-Lot. That makes no sense but there is no rule that is preventing it.

It is not recommended to consider date and time separately, but so does this contraint:

{ND-LotTenderingProcess} ${BT-13(d)-Lot <= BT-131(d)-Lot}

This compares two deadlines but only by date. The time is ignored here. This can lead to the strange condition, that BT-13(d)-Lot and BT-131(d)-Lot are at the same date, which is valid, but BT-13(t)-Lot could be later than BT-131(t)-Lot. This means deadlines could be in a wrong order and no rule prevents it.

[AnnaKSZ]

Hi Lab,

The next DST is on October 29th.

We have a notice what we submitted on October 20th (before DST).
In this notice we refer to

1. date: October 26th ((before DST))
2. date: November 10th (after DST)

Does the notice rendering define the timezone (2023-10-26+02:00 and 2023-11-10+02:00)
or the date itself (2023-10-26+02:00 and 2023-11-10+01:00)?

How we have to define the timezone in that situation?

[YvesJo]

Hi
For any new question, please start a separate discussion, else we may not detect it.
The timezone has to be present in the submitted XML instance, also it must be present at its generation. This is a key information that the user (or editing solution) has to deal with. The rendering does not add any timezone and the controls performed at notice validation rely on the existence of this information.