Timezones in start-date, end-date and birth-date

[jiripetrzelka]

During testing I encountered a server which sent timezone information in the start-date, end-date and birth-date elements, for example the value 2020-01-01+02:00. While this seems to be a valid xs:date value, I think that there is room for a potencial error on the side of client implementers from timezones west to the location of the server, because the above value can easily be parsed as 2019-12-31+01:00. If I understand it correctly, the xs:date type represents a time-zoned 24 hour interval and in this case it implies that the student was born or is about the start/end the study in the timezone of the server. But that may not be true. Wouldn't it be safer to restrict the format of these three fields to the YYYY-MM-DD format without timezone?

[kkaraogl]

I understand that for some cases, simply ignoring the timezone could cause discrepancies, though we haven't encountered it yet, when exchanging with partners. Could we further restrict the values of these elements, to not include timezone, with an xs:pattern or something?

[mkurzydlowski]

I'm not sure if restricting xs:date wouldn't cause too much implementation problems to developers. I believe that sticking too common types is a better choice, even if it means that some restrictions are only in the documentation.

I would suggest adding that the server MUST NOT use timezone for those fields and that the client MUST ignore timezone if present despite the restrictions.

[janinamincer-daszkiewicz]

DIscussed during the IF meeting on March 15, 2023. Please share your opinion.

[umesh-qs]

I'm not sure if restricting xs:date wouldn't cause too much implementation problems to developers. I believe that sticking too common types is a better choice, even if it means that some restrictions are only in the documentation.

I would suggest adding that the server MUST NOT use timezone for those fields and that the client MUST ignore timezone if present despite the restrictions.

@mkurzydlowski can you please explain this point with an example data on how sender and receiver should act.

[mkurzydlowski]

Sender MUST NOT send those dates as 2020-01-01+02:00 but rather 2020-01-01. Receiver MUST treat 2020-01-01+02:00 as 2020-01-01, without taking into account his local timezone.

[umesh-qs]

Sender MUST NOT send those dates as 2020-01-01+02:00 but rather 2020-01-01. Receiver MUST treat 2020-01-01+02:00 as 2020-01-01, without taking into account his local timezone.

If it is MUST for sender then why would there be a date with format "2020-01-01+02:00"? Receiver MUST reject it, if the format is "2020-01-01+02:00". Why do we want to create this confusion?

[mkurzydlowski]

There is never a possibility to reject bad get response. As a client we always have to deal with the data we receive. We might either try to interpret it, when the data is almost valid (like here), or hide it from the user with an appropriate message.

I propose ignoring the timezone (and reporting the issue to EWP reporting tool) but from your response I see that you want do discuss an approach were we mandate not processing an LA get response that uses timezone in a birth date?

PS. I don't see much confusion in my proposal. I just wanted to specify an edge case so it is appropriately handled by the client.

[umesh-qs]

There is never a possibility to reject bad get response. As a client we always have to deal with the data we receive. We might either try to interpret it, when the data is almost valid (like here), or hide it from the user with an appropriate message.

I propose ignoring the timezone (and reporting the issue to EWP reporting tool) but from your response I see that you want do discuss an approach were we mandate not processing an LA get response that uses timezone in a birth date?

PS. I don't see much confusion in my proposal. I just wanted to specify an edge case so it is appropriately handled by the client.

There should be no scope of such case. By adding such description you are diluting the requirement. If there is some wrong data passed by the sender, receiver should show it in error to their clients and not ignore it. Sender needs to fix it, rather then receiver ignoring it. This is how it should be everywhere. EWP is at a stage where strict checks are needed from both sender and receiver side.

[mkurzydlowski]

I'm not voting against your proposal, so lets hear other voices.

[janinamincer-daszkiewicz]

I'm not voting against your proposal, so lets here other voices.

You don't have voting rights anyway. Neither myself ;)

[umesh-qs]

There is never a possibility to reject bad get response. As a client we always have to deal with the data we receive. We might either try to interpret it, when the data is almost valid (like here), or hide it from the user with an appropriate message. I propose ignoring the timezone (and reporting the issue to EWP reporting tool) but from your response I see that you want do discuss an approach were we mandate not processing an LA get response that uses timezone in a birth date? PS. I don't see much confusion in my proposal. I just wanted to specify an edge case so it is appropriately handled by the client.

There should be no scope of such case. By adding such description you are diluting the requirement. If there is some wrong data passed by the sender, receiver should show it in error to their clients and not ignore it. Sender needs to fix it, rather then receiver ignoring it. This is how it should be everywhere. EWP is at a stage where strict checks are needed from both sender and receiver side.

Just to add. Sender is a sender for n number of receivers. So it is better sender fixes it, rather then n number of receivers making changes to ignore it.

[janinamincer-daszkiewicz]

There should be no scope of such case.

On the one hand I agree with your strict rule. On the other there are some evident fatal errors (like email which is a MUST and does not pass validation) and some non fatal, where the meaning is obvious (like birth date with time zone). In the second you may show the warning but nevertheless accept the answer and process it properly.

I see two options to vote, let's wait, may be more will show up.

Just to add. Sender is a sender for n number of receivers. So it is better sender fixes it, rather then n number of receivers making changes to ignore it.

That's of course true. This is the reason for the MUST on the sender side.

[umesh-qs]

There should be no scope of such case.

On the one hand I agree with your strict rule. On the other there are some evident fatal errors (like email which is a MUST and does not pass validation) and some non fatal, where the meaning is obvious (like birth date with time zone). In the second you may show the warning but nevertheless accept the answer and process it properly.

This is going to be redundant. There will be no such case. We will not accept it and there will be no option for the sender but to comply and make changes, because most likely they would be partner with at least one of our client.

I see two options to vote, let's wait, may be more will show up.

Just to add. Sender is a sender for n number of receivers. So it is better sender fixes it, rather then n number of receivers making changes to ignore it.

That's of course true. This is the reason for the MUST on the sender side.

[janinamincer-daszkiewicz]

By the way, that's a great opportunity to remind all that in monitoring you can see what kind of erroneous data, not compliant with the specification, which have not been validated on a server side, are send to the client and then reported in the tracking system. Go to Stats portal and use the URL below replacing $$$ with the your name as the provider

https://stats.erasmuswithoutpaper.eu/monitoring?date_from=2023-02-01&server_provider=$$$

[umesh-qs]

By the way, that's a great opportunity to remind all that in monitoring you can see what kind of erroneous data, not compliant with the specification, which have not been validated on a server side, are send to the client and then reported in the tracking system. Go to Stats portal and use the URL below replacing $$$ with the your name as the provider

https://stats.erasmuswithoutpaper.eu/monitoring?date_from=2023-02-01&server_provider=$$$

This is good. We will check and fix any error on our side.

[janinamincer-daszkiewicz]

As mentioned in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/108#issuecomment-1483802902, according to recommendations of DG EAC, this set of changes to the family of IIA APIs will be issued as the major stable release. There will be enough time for all to implement the planned set of changes. Which means that we can choose more strict rules and follow the proposal: a sender MUST NOT SEND time zones in the discussed use cases, a receiver MUST REJECT dates with time zones in the discussed use cases.