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 erasmus-without-paper/ewp-specs-api-iias#108 (comment), 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.

[umesh-qs]

This issue has propped up again in recent IF call. Was anything finalized? Is timezone allowed in fields like DOB? If so then what date should be taken as DOB as asked by Jiri when raising this issue.

[demilatof]

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.

Why do we use the XML language if we keep on using a particular data type and in the documentation we add restrictions that have nothing to do with the XML philosophy?
If we need a simple date, we have just to use the right XSD, something like this:

<xs:element name="birth-date" minOccurs="0" maxOccurs="1">
    <xs:simpleType>
        <xs:restriction base="xs:date">
            <xs:pattern value="\d{4}-\d\d-\d\d" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

The above code should avoid any misunderstood: the date can only be valid or not valid, it cannot be valid for someone and not valid for someone else.

(the same for the xs:language if you want to exclude UND you have to rewrite the type as a list of allowed values).

[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.

Why do we use the XML language if we keep on using a particular data type and in the documentation we add restrictions that have nothing to do with the XML philosophy? If we need a simple date, we have just to use the right XSD, something like this:

<xs:element name="birth-date" minOccurs="0" maxOccurs="1">
    <xs:simpleType>
        <xs:restriction base="xs:date">
            <xs:pattern value="\d{4}-\d\d-\d\d" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

The above code should avoid any misunderstood: the date can only be valid or not valid, it cannot be valid for someone and not valid for someone else.

(the same for the xs:language if you want to exclude UND you have to rewrite the type as a list of allowed values).

Hi @demilatof .. I do not think DG EAC is interested in making changes to the specification anytime soon. The question was without changes in the specification how should this be interpreted. I thought this was already discussed and confirmed by DG EAC in IF call. I am just looking for what was approved by DGEAC. If the decision was to allow timezone in date field, then which date must be shown to the end user, "2020-01-01" or "2019-12-31".

Coming to future changes to the specification. Since timezone is optional xs:date, mention of restriction in documentation goes fine with XML language definition. I would have agreed with you if timezone was mandatory.
Using MUST for sender to not to send and MUST for receiver to ignore is contradictory. As a sender I will say that I can send timezone since receiver MUST ignore. And as a receiver I will say I can restrict since sender MUST not be sending.

[bvalero-umh]

I agree with the proposal of @mkurzydlowski Dates MUST be sent with no time-zone. In case this is not possible because we don't want more changes in the specification, at least it should be RECOMMENDED. In any case, clients MUST ignore those time-zones.

I would bet that in 99% of cases these time-zones are added silently by the API implementations depending on the development language or library, and the developers and users are not aware of them.

[umesh-qs]

Did a quick search for Java and found below for sender to use. Not an expert so please correct it this is wrong. Similar to this change would have to be done at the receiver end. So what is the challenge to say that sender MUST not sent timezone in a date field?

XmlAdapter.class
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.xml.bind.annotation.adapters.XmlAdapter;

public class DateAdapter extends XmlAdapter<String, Date> {
    
    private final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");

    @Override
    public Date unmarshal(String v) throws Exception {
        return dateFormat.parse(v);
    }

    @Override
    public String marshal(Date v) throws Exception {
        return dateFormat.format(v);
    }
}



Using the new class 
import java.util.Date;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;

@XmlRootElement
public class MyEntity {

    private Date myDate;

    @XmlJavaTypeAdapter(DateAdapter.class)
    public Date getMyDate() {
        return myDate;
    }

    public void setMyDate(Date myDate) {
        this.myDate = myDate;
    }

    // Other fields and methods
}

[fioravanti-unibo]

Did a quick search for Java and found below for sender to use. Not an expert so please correct it this is wrong. Similar to this change would have to be done at the receiver end. So what is the challenge to say that sender MUST not sent timezone in a date field?

XmlAdapter.class
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.xml.bind.annotation.adapters.XmlAdapter;

public class DateAdapter extends XmlAdapter<String, Date> {
    
    private final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");

    @Override
    public Date unmarshal(String v) throws Exception {
        return dateFormat.parse(v);
    }

    @Override
    public String marshal(Date v) throws Exception {
        return dateFormat.format(v);
    }
}



Using the new class 
import java.util.Date;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;

@XmlRootElement
public class MyEntity {

    private Date myDate;

    @XmlJavaTypeAdapter(DateAdapter.class)
    public Date getMyDate() {
        return myDate;
    }

    public void setMyDate(Date myDate) {
        this.myDate = myDate;
    }

    // Other fields and methods
}

Hi Umesh, the challenge is plain and simple: xs:date is based on an ISO specification which is a standard.
The ISO standard says that the timezone in the date is admitted (a sender CAN use it) and you MUST parse it.

You cannot restrict an ISO standard and and cannot change it.
If you want to change the spec you must change the standard or create another one.

BTW, where is the problem in adopting a standard correct, library, compliant with the standard and trying to stop using an hand made parser?

[umesh-qs]

Did a quick search for Java and found below for sender to use. Not an expert so please correct it this is wrong. Similar to this change would have to be done at the receiver end. So what is the challenge to say that sender MUST not sent timezone in a date field?

XmlAdapter.class
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.xml.bind.annotation.adapters.XmlAdapter;

public class DateAdapter extends XmlAdapter<String, Date> {
    
    private final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");

    @Override
    public Date unmarshal(String v) throws Exception {
        return dateFormat.parse(v);
    }

    @Override
    public String marshal(Date v) throws Exception {
        return dateFormat.format(v);
    }
}



Using the new class 
import java.util.Date;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;

@XmlRootElement
public class MyEntity {

    private Date myDate;

    @XmlJavaTypeAdapter(DateAdapter.class)
    public Date getMyDate() {
        return myDate;
    }

    public void setMyDate(Date myDate) {
        this.myDate = myDate;
    }

    // Other fields and methods
}

Hi Umesh, the challenge is plain and simple: xs:date is based on an ISO specification which is a standard. The ISO standard says that the timezone in the date is admitted (a sender CAN use it) and you MUST parse it.

You cannot restrict an ISO standard and and cannot change it. If you want to change the spec you must chenge the standard or create another one.

BTW, where is the problem in adopting a standard correct, library, compliant with the standard and trying to stop using an hand made parser?

To answer your point let me point to

<xs:element name="hei-id" type="xs:string" minOccurs="1" maxOccurs="1">
               <xs:annotation>
                   <xs:documentation>
                       SCHAC ID of the institution. Immutable.
                       https://github.com/erasmus-without-paper/ewp-specs-api-registry/#schac-identifiers

                       Clients can fetch more information on this HEI from the Institutions API
                       served on the HEI's servers.
                   </xs:documentation>
               </xs:annotation>
           </xs:element>

Even though the type is xs:string, but the actual value in is governed by the xs:documentation. And there are many such examples. So I am not sure how all of a sudden there is concern about being strict on standards.

For now all we need to know what date to be shown to the end user when DOB is received like "2020-01-01-02:00". Is it we show 2020-01-01 or we show 2019-12-31? Unfortunately DGEAC has not been able to answer this.

[umesh-qs]

Did a quick search for Java and found below for sender to use. Not an expert so please correct it this is wrong. Similar to this change would have to be done at the receiver end. So what is the challenge to say that sender MUST not sent timezone in a date field?

XmlAdapter.class
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.xml.bind.annotation.adapters.XmlAdapter;

public class DateAdapter extends XmlAdapter<String, Date> {
    
    private final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");

    @Override
    public Date unmarshal(String v) throws Exception {
        return dateFormat.parse(v);
    }

    @Override
    public String marshal(Date v) throws Exception {
        return dateFormat.format(v);
    }
}



Using the new class 
import java.util.Date;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;

@XmlRootElement
public class MyEntity {

    private Date myDate;

    @XmlJavaTypeAdapter(DateAdapter.class)
    public Date getMyDate() {
        return myDate;
    }

    public void setMyDate(Date myDate) {
        this.myDate = myDate;
    }

    // Other fields and methods
}

Hi Umesh, the challenge is plain and simple: xs:date is based on an ISO specification which is a standard. The ISO standard says that the timezone in the date is admitted (a sender CAN use it) and you MUST parse it.

"MUST parse it". Where does the specs say how to parse it? And if there is nothing in specification about it, so where is the question of MUST?

You cannot restrict an ISO standard and and cannot change it. If you want to change the spec you must change the standard or create another one.

BTW, where is the problem in adopting a standard correct, library, compliant with the standard and trying to stop using an hand made parser?

[CarlesE-BCN]

Hi,
The main problem I see is that some providers are now being stricter with the date format. Then, those systems that send time zone to date, are finding that an LA that signed everything correctly, now we cannot make modifications because the target system does not accept the LA that it had previously accepted. This is causing students not to be able to have their LA signed. We were in this case, we had to quickly remove the timezone to be able to manage some LAs.
If you are going to look at the API specification and you do not know that there is a thread like this, then you do not know that timezone cannot be placed.
Therefore, in the specifications it should be indicated that the time zone should not be sent and in case of doing so, the receiver will ignore this information.

[demilatof]

Therefore, in the specifications it should be indicated that the time zone should not be sent and in case of doing so, the receiver will ignore this information.

But this is the old coding fashion, when there was not internet and someone developed a software to spread to everyone.
Now, with XML, if we need to change the specifications, we have to change them in the right way, that exclude using documentation to say that a given type must be managed outside international and universally accepted specifications.

The problem is that someone most probably compares dates by string or, worst, parse XML as a string and not by mean of a proper tool that should solve the Timezone.

According to all who complain about the problem, there is no way to book a flight due to the different time zone.

[umesh-qs]

For now all we need to know what date to be shown to the end user when DOB is received like "2020-01-01-02:00". Is it we show 2020-01-01 or we show 2019-12-31? Unfortunately DGEAC has not been able to answer this.

Can someone help answer this. I keep hearing that DG EAC reads these discussions and are eager to participate. If they are reading, can they answer this?

[skishk]

For now all we need to know what date to be shown to the end user when DOB is received like "2020-01-01-02:00". Is it we show 2020-01-01 or we show 2019-12-31? Unfortunately DGEAC has not been able to answer this.

is the problem just this one? only need a response from DG EAC? so the problem is not to receive a time zone if i understand well ?!

[umesh-qs]

but until September 2024... did you have problems with other providers/partners/institutions? how did you manage them before September 2024? when is the first date your system was online in production?!

How is this question related to the basic question of how to handle such dates.
And I already mentioned we were showing +/-1 day and client's were getting confused. What is the point of asking this again and again.
Instead you have not answered why you are sending timezone, when it is optional in xs:date

[skishk]

but until September 2024... did you have problems with other providers/partners/institutions? how did you manage them before September 2024? when is the first date your system was online in production?!

How is this question related to the basic question of how to handle such dates. And I already mentioned we were showing +/-1 day and client's were getting confused. What is the point of asking this again and again. Instead you have not answered why you are sending timezone, when it is optional in xs:date

thank you for your no answer . i asked because usually we discuss problems not auto-genereted problems.
using a library that is ISO compliant.
that's it on my side to contribute to a easy and fast solution. fortunately we have no problems on that.

[demilatof]

but until September 2024... did you have problems with other providers/partners/institutions? how did you manage them before September 2024? when is the first date your system was online in production?!

How is this question related to the basic question of how to handle such dates. And I already mentioned we were showing +/-1 day and client's were getting confused. What is the point of asking this again and again. Instead you have not answered why you are sending timezone, when it is optional in xs:date

We are not responsible for your wrong coding; if you want to parse manually the XML string, please ask how to do in some W3C's forum.
If you use JAXB or any other well done tool XML Standard compliant, you'll always obtain the date inserted by the sender, nothing matters if there is or not a time zone in the element.
You can play with the attached code; you need some jars:

• istack-commons-runtime-3.0.jar
• jakarta.activation-api-2.1.3.jar
• jakarta.xml.bind-api-3.0.0.jar
• jaxb-core-3.0.0.jar
• jaxb-impl-3.0.0.jar

java -classpath .:./lib/* xml.testxmldate.TestDateToXml 2020 01 01 > example.xml

you can add -Duser.timezone="GMT-2" to simulate whatever default system timezone

Then you can launch

java -classpath .:./lib/* xml.testxmldate.TestDateToXml example.xml

to read again the file (that, by default, have the timezone inside) adding eventually -Duser.timezone="GMT+10" to simulate a different received system time.
You always obtain 2020-01-01

Finally, you can also edit the xml and completely remove the time zone from it, leaving 2020-01-01
When you read it, you always obtain the same date.
The changes are always inside the Timezone, not in the date.

I hope that this can close the question, stressing out that if a standard type is used, it's a hazard thinking to limit it by words.

xml.zip

[umesh-qs]

but until September 2024... did you have problems with other providers/partners/institutions? how did you manage them before September 2024? when is the first date your system was online in production?!

How is this question related to the basic question of how to handle such dates. And I already mentioned we were showing +/-1 day and client's were getting confused. What is the point of asking this again and again. Instead you have not answered why you are sending timezone, when it is optional in xs:date

We are not responsible for your wrong coding; if you want to parse manually the XML string, please ask how to do in some W3C's forum. If you use JAXB or any other well done tool XML Standard compliant, you'll always obtain the date inserted by the sender, nothing matters if there is or not a time zone in the element. You can play with the attached code; you need some jars:

• istack-commons-runtime-3.0.jar
• jakarta.activation-api-2.1.3.jar
• jakarta.xml.bind-api-3.0.0.jar
• jaxb-core-3.0.0.jar
• jaxb-impl-3.0.0.jar

java -classpath .:./lib/* xml.testxmldate.TestDateToXml 2020 01 01 > example.xml

you can add -Duser.timezone="GMT-2" to simulate whatever default system timezone

Then you can launch

java -classpath .:./lib/* xml.testxmldate.TestDateToXml example.xml

to read again the file (that, by default, have the timezone inside) adding eventually -Duser.timezone="GMT+10" to simulate a different received system time. You always obtain 2020-01-01

Finally, you can also edit the xml and completely remove the time zone from it, leaving 2020-01-01 When you read it, you always obtain the same date. The changes are always inside the Timezone, not in the date.

I hope that this can close the question, stressing out that if a standard type is used, it's a hazard thinking to limit it by words.

xml.zip

I am sorry, I have still not understood. My clients work on different time zones. How will it always return 2020-01-01 unless you force some logic to always return 2020-01-01. If I just pass a datetime into any language library function it will convert to system time zone or the timezone you want to convert it into. How will it always return "2020-01-01" unless you forcefully want to get that value.

[umesh-qs]

Lets take an example, if I get 2020-01-01+05:00, my mysql DB field is a date and not datetime . So I convert this to UTC 2019-12-31T19:00 UTC and save 2019-12-31. This is what will be show to the end user.

[demilatof]

I am sorry, I have still not understood. My clients work on different time zones. How will it always return 2020-01-01 unless you force some logic to always return 2020-01-01. If I just pass a datetime into any language library function it will convert to system time zone or the timezone you want to convert it into. How will it always return first part of the DOB unless you forcefully want to get that value.

Because you always have an object that is a couple of (date, Timezone).
When you create (as a sender) 2020-01-01 and add the Timezone (e.g. -2), you obtain the string 2020-01-01-02
When you read (ad receiver) the string 2020-01-01-02 with a different Timezone e.g.) +3 you obtain from the xml always an object that says 2020-01-01 and time zone -2

Everything is happening later is yours matter, you don't have to get 2020-01-01 and convert in your time zone, you have to manage 2020-01-01 as it is, as a varchar in your DB if you're in trouble with different time systems of your client, but this part is outside the EWP.

[umesh-qs]

I am sorry, I have still not understood. My clients work on different time zones. How will it always return 2020-01-01 unless you force some logic to always return 2020-01-01. If I just pass a datetime into any language library function it will convert to system time zone or the timezone you want to convert it into. How will it always return first part of the DOB unless you forcefully want to get that value.

Because you always have an object that is a couple of (date, Timezone). When you create (as a sender) 2020-01-01 and add the Timezone (e.g. -2), you obtain the string 2020-01-01-02 When you read (ad receiver) the string 2020-01-01-02 with a different Timezone e.g.) +3 you obtain from the xml always an object that says 2020-01-01 and time zone -2

Everything is happening later is yours matter, you don't have to get 2020-01-01 and convert in your time zone, you have to manage 2020-01-01 as it is, as a varchar in your DB if you're in trouble with different time systems of your client, but this part is outside the EWP.

So the end user will be shown DOB in timezone like 2020-01-01+05:00 or 2019-12-31T19:00 UTC and not YYYY-MM-DD?

[demilatof]

So the end user will be shown DOB in timezone like 2020-01-01+05:00 or 2019-12-31T19:00 UTC and not YYYY-MM-DD?

Why do you want to show a time zone to the end user?
The sender has said 2020-01-01 plus a Timezone -2; you read 2020-01-01 plus a Timezone -2, why do you want to play further with time zones? Show 2020-01-01 and you have finished

[umesh-qs]

So the end user will be shown DOB in timezone like 2020-01-01+05:00 or 2019-12-31T19:00 UTC and not YYYY-MM-DD?

Why do you want to show a time zone to the end user? The sender has said 2020-01-01 plus a Timezone -2; you read 2020-01-01 plus a Timezone -2, why do you want to play further with time zones? Show 2020-01-01 and you have finished

So the whole point is that I remove the timezone from the date field and use it everywhere. And all this while I was thinking there is some magic ISO library (claimed by Janina) that will give the correct date irrespective of timezone. This is exactly what I mentioned can be done on sender side in my comment here #28 (comment) . And this is what I was asking, where does the specification say to remove the timezone and then use the YYYY-MM-DD part of the date.

[jiripetrzelka]

@jiripetrzelka started this issue, could you please share your solution with the community?

We ignore/remove the timezone if the server includes it in the response.

[umesh-qs]

@jiripetrzelka started this issue, could you please share your solution with the community?

We ignore/remove the timezone if the server includes it in the response.

Ok. Every one pointing to the custom parsing, which is to treat the incoming date with timestamp as a string, strip out the timestamp part and use the YYYY-MM-DD.
So the question remains, how is this standard ISO parsing as mentioned by Janina? And if is not standard parsing, shouldn't it be in the specification?

[janinamincer-daszkiewicz]

how is this standard ISO parsing as mentioned by Janina?

Where? I said

stick to the proper tools - there are for any language.

This has been very precisely demonstrated by @demilatof.

[demilatof]

If you are using time zone independant values:
Omit zone offset
Ignore zone offset on values received
If a zone offset is required, use UTC (offset = 0)

https://www.w3.org/TR/timezone/#guidelines

For time zone independent values (such as a list of employee birthdays): Omit the zone offset.
When processing, ignore any zone offset values in these fields.
When storing, strip off any zone offset values since zone changes are probably an artifact of other processing.

https://www.w3.org/TR/timezone/#xmlschema

Now you have even the W3C's official position.
Any further doubts?

[umesh-qs]

If you are using time zone independant values:
Omit zone offset

@demilatof @janinamincer-daszkiewicz You answered what I was saying. Sender MUST Omit. Thanks. So lets get this fixed from sender side.

Ignore zone offset on values received

If a zone offset is required, use UTC (offset = 0)

https://www.w3.org/TR/timezone/#guidelines

For time zone independent values (such as a list of employee birthdays): Omit the zone offset.
When processing, ignore any zone offset values in these fields.
When storing, strip off any zone offset values since zone changes are probably an artifact of other processing.

https://www.w3.org/TR/timezone/#xmlschema

Now you have even the W3C's official position. Any further doubts?

[umesh-qs]

Did a quick search for Java and found below for sender to use. Not an expert so please correct it this is wrong. Similar to this change would have to be done at the receiver end. So what is the challenge to say that sender MUST not sent timezone in a date field?

XmlAdapter.class
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.xml.bind.annotation.adapters.XmlAdapter;

public class DateAdapter extends XmlAdapter<String, Date> {
    
    private final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");

    @Override
    public Date unmarshal(String v) throws Exception {
        return dateFormat.parse(v);
    }

    @Override
    public String marshal(Date v) throws Exception {
        return dateFormat.format(v);
    }
}



Using the new class 
import java.util.Date;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;

@XmlRootElement
public class MyEntity {

    private Date myDate;

    @XmlJavaTypeAdapter(DateAdapter.class)
    public Date getMyDate() {
        return myDate;
    }

    public void setMyDate(Date myDate) {
        this.myDate = myDate;
    }

    // Other fields and methods
}

Hi Umesh, the challenge is plain and simple: xs:date is based on an ISO specification which is a standard. The ISO standard says that the timezone in the date is admitted (a sender CAN use it) and you MUST parse it.

This is what ISO standard says. Thanks to @demilatof and confirmation from @janinamincer-daszkiewicz . Can you please point to any other specification.

You cannot restrict an ISO standard and and cannot change it. If you want to change the spec you must change the standard or create another one.

BTW, where is the problem in adopting a standard correct, library, compliant with the standard and trying to stop using an hand made parser?

[umesh-qs]

But your specification is not clear.

ISO is not clear?

You just confirmed below ISO specification that says to OMIT timezone in timezone independent values. And I am still to get names of provider you know are sending timezone in date field. I expect a fair approach when naming provider in public forum. I hope DG EAC is seeing this.

So again why is it being forced by DGEAC?

DG EAC again?

[demilatof]

I think you had your answers; if you use on of the tool already available, you will have nothing to do, just pick the date.
Someone else has already studied the time zone issue and made a good implementation.
If you want to parse the XML element as a string, you must be sure to do in the right way, but this is your problem, not of the community.
The EWP community has the full right to expect that your own parsing is done in the right way, nothing more.
But you cannot pretend that the specification will be modified or blended just to facilitate your developing.

[umesh-qs]

Omit zone offset

EWP community also has some providers who are quite selective in pointing the wrong of a particular implementation and defending the wrong of some other implementation, as and when it suits them.
EWP community according to you expects proper parsing from the receiver end, but not proper OMIT at senders end. Isn't it a double standard from EWP community you are referring to? Can you or anyone else from your EWP community please explain the meaning of "Omit zone offset"?

[demilatof]

Please, read carefully, you are only trying to put in a mess something that is clear:

If you are using time zone independant values:
Omit zone offset
Ignore zone offset on values received
If a zone offset is required, use UTC (offset = 0)

https://www.w3.org/TR/timezone/#guidelines

For time zone independent values (such as a list of employee birthdays):
Omit the zone offset.
When processing, ignore any zone offset values in these fields.
When storing, strip off any zone offset values since zone changes are probably an artifact of other processing.

https://www.w3.org/TR/timezone/#xmlschema

If you or your tool can omit the Timezone value, avoiding to be shown in the element, do it.
But if you cannot, this is not a problem, who receive the value can ignore it.
So, what is your problem now?

[umesh-qs]

Please, read carefully, you are only trying to put in a mess something that is clear:

If you are using time zone independant values:
Omit zone offset
Ignore zone offset on values received
If a zone offset is required, use UTC (offset = 0)

https://www.w3.org/TR/timezone/#guidelines

For time zone independent values (such as a list of employee birthdays):
Omit the zone offset.
When processing, ignore any zone offset values in these fields.
When storing, strip off any zone offset values since zone changes are probably an artifact of other processing.

https://www.w3.org/TR/timezone/#xmlschema

If you or your tool can omit the Timezone value, avoiding to be shown in the element, do it. But if you cannot, this is not a problem, who receive the value can ignore it. So, what is your problem now?

Not sure where you read this "If you or your tool can omit the Timezone value". If your tool is not designed to OMIT as per the standards that you only pointed to, how is it a problem of EWP. As you said earlier, "this part is outside the EWP".
BTW there is no tool that cannot be designed to OMIT timezone, similar to any tool that can be designed to receive and ignore timezone. Problem is not mine, problem is always your selective thinking.

[demilatof]

Not sure where you read this "If you or your tool can omit the Timezone value". If your tool is not designed to OMIT as per the standards that you only pointed to, how is it a problem of EWP. As you said earlier, "this part is outside the EWP". BTW there is no tool that cannot be designed to OMIT timezone, similar to any tool that can be designed to receive and ignore timezone. Problem is not mine, problem is always your selective thinking.

Problem is yours, because I and many others don't have any problem.
You even haven't read the code I posted and the explanation I gave you.
In the element you receive a date plus a Timezone and any tool keeps them separated.
If you still don't understand that you have to keep a part (the date) and skip the other (the Timezone), you have a huge problem.
But really huge.

[umesh-qs]

Not sure where you read this "If you or your tool can omit the Timezone value". If your tool is not designed to OMIT as per the standards that you only pointed to, how is it a problem of EWP. As you said earlier, "this part is outside the EWP". BTW there is no tool that cannot be designed to OMIT timezone, similar to any tool that can be designed to receive and ignore timezone. Problem is not mine, problem is always your selective thinking.

Problem is yours, because I and many others don't have any problem. You even haven't read the code I posted and the explanation I gave you. In the element you receive a date plus a Timezone and any tool keeps them separated. If you still don't understand that you have to keep a part (the date) and skip the other (the Timezone), you have a huge problem. But really huge.

I don't want this to get dirty so will stick to logic. Asking again, where did you find "If you or your tool can omit the Timezone value"? You cannot interpret something that is not said just to defend your point.

If you are using time zone independant values:
Omit zone offset
Ignore zone offset on values received
If a zone offset is required, use UTC (offset = 0)

What the above points mean is system A MUST OMIT timezone when sending, system A MUST ignore timeone when receiving and system A can use UTC internally. So it is very clear that the interpretation of above 3 points is are applicable to single system. What Mr @demilatof is trying to do is, mislead by saying that system A can send timezone and system B should cover for it by ignoring it.

[demilatof]

Again, it's your problem.
W3C is clear, the solution is clear, if you're not able to manage the Timezone (in this case, simply ignoring it as sender or receiver), do something else.

If you see 2020-01-01 in the element, it's always 2020-01-01 without a time zone or with a whatever time zone.
It's really easy, let you try, you can do it. This is what W3s says (and not me), I don't understand what else you want.

[umesh-qs]

What the above points mean is system A MUST OMIT timezone when sending, system A MUST ignore timeone when receiving and system A can use UTC internally. So it is very clear that the interpretation of above 3 points is are applicable to single system. What Mr @demilatof is trying to do is, mislead by saying that system A can send timezone and system B should cover for it by ignoring it.

Please read above again. Problem is that you do not want to listen beyond what you have decided at the start of the discussion. Anything beyond what you have fixed in your mind is others problem. W3s does not say what you want to pick and choose. So please stop misleading on what W3s says. Unless there is any other specification that you want to quote I can have further discussion. Else I will pause on to this W3s specification which is clear on how individual system must behave for such dates.

[demilatof]

What the above points mean is system A MUST OMIT timezone when sending, system A MUST ignore timeone when receiving and system A can use UTC internally. So it is very clear that the interpretation of above 3 points is are applicable to single system. What Mr @demilatof is trying to do is, mislead by saying that system A can send timezone and system B should cover for it by ignoring it.

Please read above again. Problem is that you do not want to listen beyond what you have decided at the start of the discussion. Anything beyond what you have fixed in your mind is others problem. W3s does not say what you want to pick and choose. So please stop misleading on what W3s says. Unless there is any other specification that you want to quote I can have further discussion.

Please, stop seeing in other your problems and start reading and studying, before ending in a ridiculous situation.

So it is very clear that the interpretation of above 3 points is are applicable to single system
...
Else I will pause on to this W3s specification which is clear on how individual system must behave for such dates.

W3C says (as you can read at the pages I linked above, if you open your mind and read them):

Use cases are provided to help choose

an approach that ensures that geographically distributed applications work well

All that said, my selective thinking has just decided to select you out because you're only trying to find a way to justify your poor coding; and even this is your problem.

[umesh-qs]

What the above points mean is system A MUST OMIT timezone when sending, system A MUST ignore timeone when receiving and system A can use UTC internally. So it is very clear that the interpretation of above 3 points is are applicable to single system. What Mr @demilatof is trying to do is, mislead by saying that system A can send timezone and system B should cover for it by ignoring it.

Please read above again. Problem is that you do not want to listen beyond what you have decided at the start of the discussion. Anything beyond what you have fixed in your mind is others problem. W3s does not say what you want to pick and choose. So please stop misleading on what W3s says. Unless there is any other specification that you want to quote I can have further discussion.

Please, stop seeing in other your problems and start reading and studying, before ending in a ridiculous situation.

So it is very clear that the interpretation of above 3 points is are applicable to single system
...
Else I will pause on to this W3s specification which is clear on how individual system must behave for such dates.

W3C says (as you can read at the pages I linked above, if you open your mind and read them):

Use cases are provided to help choose

an approach that ensures that geographically distributed applications work well

All that said, my selective thinking has just decided to select you out because you're only trying to find a way to justify your poor coding; and even this is your problem.

Here the discussion is about specification and not about MoveOn.
Thank you for at least accepting for selective thinking and because of that selective targeting. Your problem is if people don't agree with you, then you start targeting.

[demilatof]

Here the discussion is about specification and not about MoveOn. Thank you for at least accepting for selective thinking and because of that selective targeting. Your problem is if people don't agree with you, then you start targeting.

The specification tells you to use a "xs: date", that represents a Gregorian calendar date as defined in ISO 8601 according to W3C recommendation.
W3C also says how to use it for Timezone independent values.

About this issue, the specifications are enough, nothing to discuss. If you and MoveOn are the only ones in trouble, the problem must be looked for in your code.
Have a good luck

[umesh-qs]

Here the discussion is about specification and not about MoveOn. Thank you for at least accepting for selective thinking and because of that selective targeting. Your problem is if people don't agree with you, then you start targeting.

The specification tells you to use a "xs: date", that represents a Gregorian calendar date as defined in ISO 8601 according to W3C recommendation. W3C also says how to use it for Timezone independent values.

About this issue, the specifications are enough, nothing to discuss. If you and MoveOn are the only ones in trouble, the problem must be looked for in your code. Have a good luck

Back to circle one and same rant again and again. Nothing concrete. Not worth responding to you. MoveOn will do whatever is correct as per specification. But that does not mean others can be allowed to screw. Finally I will pause.

[janinamincer-daszkiewicz]

Summary presented during the IF meeting on 2024-11-13:

• Let’s follow the ISO guidelines and best practices:
  - Do not send.
  - Do not reject.
  - Do not show in the interface.
• Any other decisions are postponed to ESCI phase II.