Loading ...
Sorry, an error occurred while loading the content.
 

RE: [ISO8601] OIC seminar - clean version ISP e-mail

Expand Messages
  • Tex Texin
    This mail clarifies that you changed domain servers. Changes like this take as much as 72 hours to spread across the net. The problem of the mail delay has
    Message 1 of 6 , Jan 12, 2006
      This mail clarifies that you changed domain servers. Changes like this take
      as much as 72 hours to spread across the net.

      The problem of the mail delay has nothing to do with date-time stamp
      formats, and in fact the net doesn't care about that information, it just
      logs the time of the events.

      Although there are problems with some aspects of the 8601 standard, this
      mail does not clarify nor identify a problem.

      I think it is time to stop flogging this particular issue as well as the
      seminar ads.

      I don't like waiting 20 minutes for the bus, but there is no point trying to
      change the clock face to fix it.
      ;-)

      Tex Texin
      Internationalization Architect, Yahoo! Inc.




      > -----Original Message-----
      > From: ISO8601@yahoogroups.com
      > [mailto:ISO8601@yahoogroups.com] On Behalf Of Stephen GOULD
      > Sent: Friday, January 13, 2006 3:14 AM
      > To: ISO8601@yahoogroups.com
      > Cc: ebxml-dev@...; eBusiness Interest
      > Subject: Re: [ISO8601] OIC seminar - clean version ISP e-mail
      >
      >
      > 11:03 Fri 13 Jan 2006 REF:AECSTFE1
      >
      > TO: ISO 8601 cc ebXML
      >
      > Sorry Piebald - the cut & paste caused the colour parameters
      > to distort the e-mail message - this is the clean version to
      > illustrate how in e-mail international communications the
      > time and date are currently
      > inoperable for Good Governance processes
      >
      > Please note the OIC is holding an eSeminar on this issue on Tue 24
      > Jan 2006 on the proposed joint-venture project http://www.oic.org
      >
      > If anyone would like to submit a paper or explanation on this
      > issue it will be included in the Seminar papers
      >
      > NEXT STEPS
      >
      > All feedback appreciated
      >
      > Regards
      >
      > Stephen GOULD
      > 11:05 F 2006/01/13 Syd 2065
      >
      > 08:14 Wed 11 Jan 2006 REF:AECSTFE1
      >
      > ISO8601/ebXML Dates & Time-zones BBS
      > http://www.godlikeproductions.com/bbs/message.php?messageid=19
      > 7873&show
      > date=&mpage=
      >
      > TO: ISO 8601 cc ebXML
      > eCommerce
      > Interested Parties
      >
      > Piebald - here is a real current situation of the time date
      > problem - and
      > this is 18 years after ISO8601 was published as a date time Standard
      > and before most e-mail systems had been released !
      >
      > PROBLEM: On Tue 10 Jan 2006 we could not send/receive e-mails or
      > access one of key project web-sites in the US.
      >
      > Here is the date and time sequence of the e-mails with the
      > ISP Support.
      > The content of the e-mails is provided further down
      >
      > We record the time and date on the e-mail because the UTC time
      > bears no relationship to the local time
      >
      > 1 E-mail to ISP Support "Please Advise"
      > Tue 2006/01/10 22:58
      > UTC Sent: Tuesday, January 10, 2006 6:03 PM
      >
      > 2 Response from ISP Support
      > 10 Jan 06, at 9:07
      >
      > 3 Reply to ISP Support
      > 01:29 W 2006/01/11 Syd 2089
      > UTC Sent: Tuesday, January 10, 2006 8:32 PM
      >
      > 3 2nd Response from ISP
      > Tue, 10 Jan 2006 15:27:30 -0500
      >
      > Hence the proposal for an ISO8601/ebXML workgroup to sort this
      > out and have a standard time and date format which is linked
      > to the time-zone
      >
      > As I am sure you can appreciate, this date and time problem
      > with e-mail renders eCommerce and automated business processes
      > for SMEs as inoperable.
      >
      > NEXT STEPS
      >
      > Will you join the work-group to try to sort this out ?
      >
      > We should be able to apply for Government funding from both the
      > US and Australian Governments to sort this out for the Electronic
      > Commerce element of the Aus-USA FTA
      >
      > If you would like to participate as a member of the OIC please
      > register on
      > http://www.oic.org/3d1.htm
      >
      > Regards
      >
      > Stephen GOULD
      > Chair
      > XML & ECommerce Special Interest Group
      > OPEN INTERCHANGE CONSORTIUM
      > 09:29 W 2006/01/11 Syd 2065
      >
      > E: sgould@...
      > W: http://www.oic.org/z/XZIG
      >
      > Subject: RE: Please advise
      > Date sent: Tue, 10 Jan 2006 15:27:30 -0500
      > From: "Support"
      > To: <sggould@...>
      >
      > Hello,
      >
      > If it still does not work, you may need wait a few more hours
      > for the
      > email to updated on the email server.
      >
      > Please see the following Knowledge Base article for
      > instructions on how
      > to set up your mail client.
      >
      > If you have any further questions, please let us know.
      >
      > Thank you,
      >
      > Robert
      >
      > -----Original Message-----
      >
      > From: Stephen GOULD [mailto:sggould@...]
      > Sent: Tuesday, January 10, 2006 8:32 PM
      > To: Support
      > Subject: RE: Please advise
      >
      > Thanks Robert - have changed the domain servers SMEEMS.NET:
      > Name Servers Successfully Updated
      >
      >
      > Code: RG99HJe8uRWZ4oUybgFFogqw
      >
      > but as yet cannot download any e-mails - how long does it take ?
      >
      > Regards
      >
      > Stephen GOULD
      > 01:29 W 2006/01/11 Syd 2089
      >
      > On 10 Jan 06, at 9:07, Support wrote:
      >
      > > Hello,
      > >
      > > It appears cause of the error is that the domain is
      > pointing to the
      > > old ewebcity nameservers. You will need to update this to new
      > > nameservers:
      > >
      > > Please view the following link:
      > >
      > > You will need to point your domain to point to the name servers.
      > > Please see this Knowledge Base article for complete instructions:
      > >
      > > If we can help you with anything else, please let us know.
      > >
      > >
      > > Thank you,
      > >
      > > Robert
      > >
      > > -----Original Message-----
      > > From: Stephen GOULD [mailto:sggould@...]
      > > Sent: Tuesday, January 10, 2006 6:03 PM
      > > To: Support
      > > Subject: Please advise
      > >
      > > Hi - I have been trying to send an e-mail via
      > stephen.gould@...
      > > for the last 5 hrs
      > >
      > > The time is now 22:58 Local time
      > >
      > > Is there a problem with the site, domain name or anything else ?
      > >
      > > Will it be working by 08:00 tomorrow ?
      > >
      > > Please advise if any other problem apart from a technical problem
      > >
      > > Thank you
      > >
      > > Stephen GOULD
      > >
      > > sggould@...
      > >
      > > stephen.gould@...
      > >
      > On 10 Jan 06, at 3:36, piebaldconsult wrote:
      >
      > > Currently responses to E-mails sent to the US from Australia come
      > > back with a time and date before the original message is sent !
      > >
      > > I expect if you inspect the message headers you will see
      > that that is
      > > not the case. If you and your colleagues are in the habit
      > of typing
      > > dates and times into your correspondence then you really ought to
      > > either use UTC or specify the offset from UTC along with
      > the local
      > > time. Using the numeric offset rather than some arcane
      > collection of
      > > letters will certainly be less prone to misinterpretation by any
      > > recipients including casual passers-by.
      > >
      > > This is why ISO8601 uses a numeric offset rather than a
      > textual value
      > > that can change value depending on the whims of the local
      > government
      > > hacks (or lobbyists). If something is timestamped with its
      > offset you
      > > don't have to wonder later, "what was the offset for XYZ at that
      > > time"?
      > >
      > > > Tex, Piabald and yourself seems to respond most to the ISO 8601
      > > > e-mails how do we incorporate a time zone to a UTC date ?
      > >
      > > Yes, but I don't think we agree very often.
      > >
      > >
      >
      >
      > On 12 Jan 06, at 3:17, piebaldconsult wrote:
      >
      > > > Tue 2006/01/10 22:58
      > > January 10, 2006 6:03 PM<bold></color>
      > > > </bold>10 Jan 06, at 9:07<bold>
      > > > 01:29 W 2006/01/11 Syd 2089<bold>
      > > > </bold>UTC Sent: Tuesday, January 10, 2006 8:32 PM
      > > > <color><param>0000,0000,0000</param>Tue, 10 Jan 2006
      > 15:27:30 -0500
      > >
      > > I don't see what point you're trying to make. None of the
      > examples you
      > > provide are in ISO8601 format. How can you argue that
      > ISO8601 is flawed
      > > if you don't even use it? Your examples are all reasons why
      > ISO8601 (or
      > > similar) is required for your purposes. Try using ISO8601
      > and _then_
      > > see whether or not it works, I think you'll find it does.
      > >
      > >
      > >
      > >
      > >
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      > >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
    • Fred Bone
      ... But e-mail is one of the longest-standing applications where time, though not in ISO8601 format, is sufficiently well-defined that the problems you
      Message 2 of 6 , Jan 13, 2006
        On 13 Jan 2006 at 2:44, ISO8601@yahoogroups.com said:

        > Sorry Piebald - the cut & paste caused the colour parameters to distort
        > the e-mail message - this is the clean version to illustrate how in e-mail
        > international communications the time and date are currently inoperable
        > for Good Governance processes
        >

        But e-mail is one of the longest-standing applications where time, though
        not in ISO8601 format, is sufficiently well-defined that the problems you
        complain of do not, in fact, exist.

        You said, earlier in this thread, that replies come back apparently
        earlier than the corresponding requests. If true, this is down to clock
        errors at one end or the other. No conceivable data format can deal with
        erroneous input.

        Your eaxmples:

        > 1 E-mail to ISP Support "Please Advise"
        > Tue 2006/01/10 22:58
        > UTC Sent: Tuesday, January 10, 2006 6:03 PM
        >
        > 2 Response from ISP Support
        > 10 Jan 06, at 9:07
        >
        > 3 Reply to ISP Support
        > 01:29 W 2006/01/11 Syd 2089
        > UTC Sent: Tuesday, January 10, 2006 8:32 PM
        >
        > 3 2nd Response from ISP
        > Tue, 10 Jan 2006 15:27:30 -0500

        I note that
        (1) None of the first three show the e-mail Date: header format, which is
        supposed to be definitive;
        (2) the "UTC Sent:" information on the first and third is in each case
        somewhat later than the respective "unstructured" time;
        (3) the "2nd response" appears to be about five minutes earlier than the
        "Reply ..." that precedes it: if in fact is is a response to that "reply"
        then someone's clock is wrong.
      • Stephen GOULD
        11:03 Fri 13 Jan 2006 REF:AECSTFE1 TO: ISO 8601 cc ebXML Sorry Piebald - the cut & paste caused the colour parameters to distort the e-mail message -
        Message 3 of 6 , Jan 13, 2006
          11:03 Fri 13 Jan 2006 REF:AECSTFE1

          TO: ISO 8601 cc ebXML

          Sorry Piebald - the cut & paste caused the colour parameters to distort
          the e-mail message - this is the clean version to illustrate how in
          e-mail international communications the time and date are currently
          inoperable for Good Governance processes

          Please note the OIC is holding an eSeminar on this issue on Tue 24
          Jan 2006 on the proposed joint-venture project
          http://www.oic.org

          If anyone would like to submit a paper or explanation on this issue
          it will be included in the Seminar papers

          NEXT STEPS

          All feedback appreciated

          Regards

          Stephen GOULD
          11:05 F 2006/01/13 Syd 2065

          08:14 Wed 11 Jan 2006 REF:AECSTFE1

          ISO8601/ebXML Dates & Time-zones BBS
          http://www.godlikeproductions.com/bbs/message.php?messageid=197873&show
          date=&mpage=

          TO: ISO 8601 cc ebXML
          eCommerce Interested Parties

          Piebald - here is a real current situation of the time date problem - and
          this is 18 years after ISO8601 was published as a date time Standard
          and before most e-mail systems had been released !

          PROBLEM: On Tue 10 Jan 2006 we could not send/receive e-mails or
          access one of key project web-sites in the US.

          Here is the date and time sequence of the e-mails with the ISP Support.
          The content of the e-mails is provided further down

          We record the time and date on the e-mail because the UTC time
          bears no relationship to the local time

          1 E-mail to ISP Support "Please Advise"
          Tue 2006/01/10 22:58
          UTC Sent: Tuesday, January 10, 2006 6:03 PM

          2 Response from ISP Support
          10 Jan 06, at 9:07

          3 Reply to ISP Support
          01:29 W 2006/01/11 Syd 2089
          UTC Sent: Tuesday, January 10, 2006 8:32 PM

          3 2nd Response from ISP
          Tue, 10 Jan 2006 15:27:30 -0500

          Hence the proposal for an ISO8601/ebXML workgroup to sort this
          out and have a standard time and date format which is linked
          to the time-zone

          As I am sure you can appreciate, this date and time problem
          with e-mail renders eCommerce and automated business processes
          for SMEs as inoperable.

          NEXT STEPS

          Will you join the work-group to try to sort this out ?

          We should be able to apply for Government funding from both the
          US and Australian Governments to sort this out for the Electronic
          Commerce element of the Aus-USA FTA

          If you would like to participate as a member of the OIC please
          register on
          http://www.oic.org/3d1.htm

          Regards

          Stephen GOULD
          Chair
          XML & ECommerce Special Interest Group
          OPEN INTERCHANGE CONSORTIUM
          09:29 W 2006/01/11 Syd 2065

          E: sgould@...
          W: http://www.oic.org/z/XZIG

          Subject: RE: Please advise
          Date sent: Tue, 10 Jan 2006 15:27:30 -0500
          From: "Support"
          To: <sggould@...>

          Hello,

          If it still does not work, you may need wait a few more hours for the
          email to updated on the email server.

          Please see the following Knowledge Base article for instructions on how
          to set up your mail client.

          If you have any further questions, please let us know.

          Thank you,

          Robert

          -----Original Message-----

          From: Stephen GOULD [mailto:sggould@...]
          Sent: Tuesday, January 10, 2006 8:32 PM
          To: Support
          Subject: RE: Please advise

          Thanks Robert - have changed the domain servers SMEEMS.NET:
          Name Servers Successfully Updated


          Code: RG99HJe8uRWZ4oUybgFFogqw

          but as yet cannot download any e-mails - how long does it take ?

          Regards

          Stephen GOULD
          01:29 W 2006/01/11 Syd 2089

          On 10 Jan 06, at 9:07, Support wrote:

          > Hello,
          >
          > It appears cause of the error is that the domain is pointing to the
          > old ewebcity nameservers. You will need to update this to new
          > nameservers:
          >
          > Please view the following link:
          >
          > You will need to point your domain to point to the name servers.
          > Please see this Knowledge Base article for complete instructions:
          >
          > If we can help you with anything else, please let us know.
          >
          >
          > Thank you,
          >
          > Robert
          >
          > -----Original Message-----
          > From: Stephen GOULD [mailto:sggould@...]
          > Sent: Tuesday, January 10, 2006 6:03 PM
          > To: Support
          > Subject: Please advise
          >
          > Hi - I have been trying to send an e-mail via stephen.gould@...
          > for the last 5 hrs
          >
          > The time is now 22:58 Local time
          >
          > Is there a problem with the site, domain name or anything else ?
          >
          > Will it be working by 08:00 tomorrow ?
          >
          > Please advise if any other problem apart from a technical problem
          >
          > Thank you
          >
          > Stephen GOULD
          >
          > sggould@...
          >
          > stephen.gould@...
          >
          On 10 Jan 06, at 3:36, piebaldconsult wrote:

          > Currently responses to E-mails sent to the US from Australia come
          > back with a time and date before the original message is sent !
          >
          > I expect if you inspect the message headers you will see that that is
          > not the case. If you and your colleagues are in the habit of typing
          > dates and times into your correspondence then you really ought to
          > either use UTC or specify the offset from UTC along with the local
          > time. Using the numeric offset rather than some arcane collection of
          > letters will certainly be less prone to misinterpretation by any
          > recipients including casual passers-by.
          >
          > This is why ISO8601 uses a numeric offset rather than a textual value
          > that can change value depending on the whims of the local government
          > hacks (or lobbyists). If something is timestamped with its offset you
          > don't have to wonder later, "what was the offset for XYZ at that time"?
          >
          > > Tex, Piabald and yourself seems to respond most to the ISO 8601
          > > e-mails how do we incorporate a time zone to a UTC date ?
          >
          > Yes, but I don't think we agree very often.
          >
          >


          On 12 Jan 06, at 3:17, piebaldconsult wrote:

          > > Tue 2006/01/10 22:58
          > January 10, 2006 6:03 PM<bold></color>
          > > </bold>10 Jan 06, at 9:07<bold>
          > > 01:29 W 2006/01/11 Syd 2089<bold>
          > > </bold>UTC Sent: Tuesday, January 10, 2006 8:32 PM
          > > <color><param>0000,0000,0000</param>Tue, 10 Jan 2006 15:27:30 -0500
          >
          > I don't see what point you're trying to make. None of the examples you
          > provide are in ISO8601 format. How can you argue that ISO8601 is flawed
          > if you don't even use it? Your examples are all reasons why ISO8601 (or
          > similar) is required for your purposes. Try using ISO8601 and _then_
          > see whether or not it works, I think you'll find it does.
          >
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
        • piebaldconsult
          ... which is ... case ... the ... that reply ... Exactly, it seems you are trying to rely on timestamps that were typed freestyle by the user rather than the
          Message 4 of 6 , Jan 13, 2006
            > (1) None of the first three show the e-mail Date: header format,
            which is
            > supposed to be definitive;
            > (2) the "UTC Sent:" information on the first and third is in each
            case
            > somewhat later than the respective "unstructured" time;
            > (3) the "2nd response" appears to be about five minutes earlier than
            the
            > "Reply ..." that precedes it: if in fact is is a response to
            that "reply"
            > then someone's clock is wrong.

            Exactly, it seems you are trying to rely on timestamps that were typed
            freestyle by the user rather than the automatically computer generated
            timestamps in the message headers (which ought to be ISO8601). Which
            perhaps could still be mucked with by changing the settings on the
            server.

            Stop sticking yourself in the eye with a spoon and then complaining
            that the spoon is unsafe.
          Your message has been successfully submitted and would be delivered to recipients shortly.