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

RE: [ISO8601] Re: Dates-Timezones & eBusiness

Expand Messages
  • Tex Texin
    Although I agree in general, I also think that you are going bit too far with the statement that everything should be in UTC. If dates are used in a hub for
    Message 1 of 16 , Jan 6, 2006
      Although I agree in general, I also think that you are going bit too far
      with the statement that everything should be in UTC.

      If dates are used in a hub for interchange, the date instance values may
      need to persist for a long time.
      (Essentially stored in the hub.)
      However, the rules for conversion between UTC and local times are subject to
      change.
      If a date-time really reflects a local time (e.g. the time of departure of a
      plane) it can be better to represent the local time without the time zone
      offset. The time zone offset would be determined at the point the date-time
      is actually used.

      Then if the rules for conversion to UTC change, the data is not corrupted.
      As you know, there are examples of local (or federal) governments opting to
      temporarily or permanently change the date for switching to daylight
      savings, etc.

      If I buy a ticket with a particular departure time and the conversion rules
      change after purchase, but the local time for departure under the new time
      zone law doesn't change, storing as UTC will make the time incorrect, unless
      there is a way to find all of the instances and reconvert them. That is not
      always possible.

      There are cases where date value representation should reflect the semantics
      of the date-time, ie whether it is a local time regardless of the relation
      to UTC, or a particular instant in time, in which case it is accurately
      represented by a UTC time, regardless of how it is called locally.

      Tex Texin
      Internationalization Architect, Yahoo! Inc.




      > -----Original Message-----
      > From: ISO8601@yahoogroups.com
      > [mailto:ISO8601@yahoogroups.com] On Behalf Of piebaldconsult
      > Sent: Friday, January 06, 2006 7:02 PM
      > To: ISO8601@yahoogroups.com
      > Subject: [ISO8601] Re: Dates-Timezones & eBusiness
      >
      >
      > Section 5.3.4 of ISO8601 (in the 2000 version) explains how
      > to indicate
      > your local offset from UTC, i.e. your time zone, so I have no
      > idea why
      > this thread was even started.
      >
      > And furthermore, data interchange should _not_ be made with local
      > times, only with UTC. In this respect, ISO8601 already goes
      > too far, it
      > needn't even have section 5.3.4 to achieve its goals. Any
      > perceived "problems" or "shortcomings" of ISO8601 are merely due to a
      > lack of understanding by they who can't seem to grasp the concept. If
      > you simply always use UTC in data interchange all the "problems" go
      > away.
      >
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
    • piebaldconsult
      ... rules ... time ... The departure time printed on the ticket, not being subject to data interchange (between computers), is likely to be in local time. This
      Message 2 of 16 , Jan 7, 2006
        > If I buy a ticket with a particular departure time and the conversion
        rules
        > change after purchase, but the local time for departure under the new
        time
        > zone law doesn't change, storing as UTC will make the time incorrect,

        The departure time printed on the ticket, not being subject to data
        interchange (between computers), is likely to be in local time. This is
        true of both departure and arrival time currently, as I'm sure you're
        aware.

        When things change, things change, there's no getting around it. Trying
        to pretend that it _didn't_ change simply because the effective
        departure time _appears_ the same is incorrect. You'd darn well better
        inform all your ticket holders about the change so they can plan
        accordingly, they are likely to have connections outside the affected
        locale and the arrival time at the destination will change as well.
      • Bev MARKS (Mr)
        ... All This thread is interesting because it seems to be placed within a particular context - something to do with ticket sales etc. I agree, too that the UTC
        Message 3 of 16 , Jan 8, 2006
          --- In ISO8601@yahoogroups.com, "Tex Texin" wrote:


          > Although I agree in general, I also think that you are going
          > a bit too far with the statement that everything should be in
          > UTC.



          All

          This thread is interesting because it seems to be placed within a
          particular context - something to do with ticket sales etc.

          I agree, too that the UTC format should not need changes or additions
          to be used in any particular cotext which may well necessarily
          require its own semantics to achieve a particular functionaity.

          For my particular context (see www.tpeg.org) we have chosen to simply
          use the YYYY-MM-DD T HH:MM:SS format of UTC within suitable
          declarative messages such as Message Generation Time, Start Time,
          Stop Time, Message Expiry Time - wherever in the world they are
          generated; where "Time" in this context is a shorthand for the full
          Date/Time UTC format as described.

          Operating within Europe with two main time zones and co-ordinated
          Summer Time changes we have experienced no particular problems (over
          several years) in our context of exchanging Traffic and Travel
          Information Messages. At least all time processing is using the same
          format, regardless of functionality in our context of the
          given "Time". (We have other Time types too complex to describe
          here.)

          Bev
        • mattias_flodin
          Why on earth would you use a site about conspiration theories and UFOs for discussing an ISO standard? And what is wrong with this forum?
          Message 4 of 16 , Jan 14, 2006
            Why on earth would you use a site about conspiration theories and UFOs
            for discussing an ISO standard? And what is wrong with this forum?

            --- In ISO8601@yahoogroups.com, "Stephen GOULD" <sggould@o...> wrote:
            >
            > 13:12 Sat 07 Jan 2006 REF:AECSTFN2
            > Y/R: ISO8601 Timezones
            >
            > TO: ISO8601 Special Interest Group cc ebXML Developers
            > eBusiness Interests
            >
            > BBS SET UP FOR RESPONSES
            >
            > Hi - Thanks for the responses - your right we have to get away
            > from manually typing dates in e-mails - 2 out of 2 wrong is a great
            > way to start a discussion on an electronic standard date format !
            >
            > The reason why we have a start time/date and finish time/date is
            > that, as e-mail is replacing written/typed correspondence, it
            > can consume a lot of time reading and responding to e-mails
            > particularly as part of Volunteer Special Interest Groups such as
            > ISO 8601 and ebXML.
            >
            > Hence this is way at the 1996 OIC AGM Members unanimously voted
            > to develop an eCredits process for Volunteer work
            > http://www.oic.org/M
            >
            > The BBS has been set-up so you can post your response onto it to
            > enable other interested parties join the discussion about ISO8601
            > and Time Zones.
            >
            > It has been posted on godlikeproductions.com as
            >
            > "ISO8601 & Time Zones Work Group"
            >
            > http://www.godlikeproductions.com/bbs/message.php?messageid=197873&show
            > date=&mpage=
            >
            > Look forward to working with you to spread the word on how using the
            > standard electronic date format ISO8601 can really benefit eBusiness
            > and eCommunity operations
            >
            > Regards
            >
            > Steve GOULD
            > Chair
            > OIC XML & eCommerce Special Interest Group
            > OPEN INTERCHANGE CONSORTIUM
            > 13:36 S 2006/01/07 Syd 2065
            >
            > E: sggould@o...
            > W: http://www.oic.org/z/XZIG/A/
            >
          • mattias_flodin
            ... I don t understand this last comment. Obviously, any date and time you specify is a range, if you want to view it that way. If, as you say, we can view
            Message 5 of 16 , Jan 14, 2006
              --- In ISO8601@yahoogroups.com, NGUYEN Ivy <nguyenivy@g...> wrote:
              > I think you just indicate whatever default time you use (like 00:00),
              > then use a timezone afterwards. I don't believe dates alone have
              > timezone information in ISO 8601. It wouldn't make sense, unless some
              > new provision is added like 'all dates without times that have
              > timezone information, are to be treated as 00:00 if no time is
              > stated'.
              >
              > It is true that giving a date without a timezone can cause ambiguity,
              > as at least half the world is always a different date than stated. But
              > on the flip-side, if no time within the date is stated at all, than
              > how can we have timezone information? '2000-01-01 in New York
              > (UTC-05)' means that 24-hour period lasting from 00:00--24:00 in New
              > York (timezone). Doesn't reveal much more.

              I don't understand this last comment. Obviously, any date and time you
              specify is a range, if you want to view it that way. If, as you say,
              we can view "2000-01-01" is the range [2000-01-01 T00:00, 2000-01-01
              T24:00), then the time "2001-01-01 T20" could also be seen as the
              range [2001-01-01 T20:00, 2001-01-01 T21:00).

              Any time we represent will be specified to some amount of precision.
              Just providing the date is one level of precision. Specifying the hour
              is a higher level of precision, and indicating minute and second give
              even higher precision. Since the ISO standard doesn't say whether to
              interpret a date as a time range or as a singular point in time, that
              is up to the application as far as I am concerned. Why then should you
              draw a line at which precision level time zones are used?

              If I choose to view a date as a singular point in time (much as many
              would view T20:01:02 as a singular point), then that moment will occur
              at a different local time in different time zones. Obviously we could
              specify at which second it occurs, as in "The Swedish new year occurs
              on 2006-01-01 00:00:00+01:00 and the Chinese new year occurs on
              2006-01-29 00:00:00+08:00", but it is much more convenient to say "The
              Swedish new year occurs on 2006-01-01+01 and the Chinese new year
              occurs on 2006-01-29+08".

              Perhaps the issue at hand here boils down to what is the purpose of
              introducing reduced precision into the ISO standard in the first place.

              Regards,
              Mattias Flodin
            • piebaldconsult
              First, read section 5.2.1.1; it starts with, When the application identifies the need for an expression only of a calendar date ... That is, the date and
              Message 6 of 16 , Jan 15, 2006
                First, read section 5.2.1.1; it starts with, "When the application
                identifies the need for an expression only of a calendar date" ...
                That is, the date and nothing more. It's a date, not a day.

                > I don't understand this last comment. Obviously, any date and time
                you
                > specify is a range, if you want to view it that way. If, as you say,

                Sure you can view it that way, but ISO8601 doesn't, because it would
                introduce ambiguity, but of course "by agreement of the partners in
                interchange" overrides pretty much everything.

                > we can view "2000-01-01" is the range [2000-01-01 T00:00, 2000-01-01
                > T24:00), then the time "2001-01-01 T20" could also be seen as the
                > range [2001-01-01 T20:00, 2001-01-01 T21:00).

                If you mean the range, then say the range. Remember, this standard is
                primarily for computers communicating, not humans. Certainly if I
                were typing a date into an email I wouldn't bother with the whole
                range, but when writing a program, I would tell _it_ to do so.

                And of course you would use a properly formatted "interval" for that.

                > Any time we represent will be specified to some amount of precision.

                And you can't remove the precision in between the date and timezone.
                It would be like specifying a year and day-of-the-month with no month.
                That would be "eviscerated precision".

                > is up to the application as far as I am concerned. Why then should
                you
                > draw a line at which precision level time zones are used?

                Time zones are only allowed for times. That's why they're
                called "time zones". (I want to add a "duh" to that.)

                But seriously you could try 2006/01/14T--:--:--+08:00 which is the
                closest you could come, but it's not allowed because:
                a) Truncating the seconds field of a time is not allowed
                b) Truncated times are not allowed to be combined with dates

                > 2006-01-29 00:00:00+08:00", but it is much more convenient to

                Convenient for _humans_, computers don't care.

                > Swedish new year occurs on 2006-01-01+01 and the Chinese new year
                > occurs on 2006-01-29+08".

                Do persons of chinese heritage who live in San Francisco celebrate
                the Chinese New Year at that offset? (Recognizing, of course, that
                San Franciscans do some strange things.)

                Would you celebrate the Gregorian New Year in accordance with
                Gregor's offset or your own?

                > Perhaps the issue at hand here boils down to what is the purpose of
                > introducing reduced precision into the ISO standard in the first
                place.

                It's all reduced precision, even the standard recognizes that a
                second is not the smallest unit of time. What constitutes the
                smallest meaningful unit is application-specific.

                However, the standard dictates that if time of day is specified then
                it must be in hour-sized units at most.
              • piebaldconsult
                ... Because of the black helicopters. ... Nothing wrong with this forum. It s the place to be.
                Message 7 of 16 , Jan 15, 2006
                  > Why on earth would you use a site about conspiration theories and UFOs
                  > for discussing an ISO standard?

                  Because of the black helicopters.

                  > And what is wrong with this forum?

                  Nothing wrong with this forum. It's the place to be.
                • piebaldconsult
                  ... Yay! A happy customer. Go forth and spread the word! Perhaps you could write up a small article that describes what sorts of things you use timestamps for
                  Message 8 of 16 , Jan 20, 2006
                    > Operating within Europe with two main time zones and co-ordinated
                    > Summer Time changes we have experienced no particular problems (over
                    > several years) in our context of exchanging Traffic and Travel
                    > Information Messages. At least all time processing is using the same

                    Yay! A happy customer. Go forth and spread the word!

                    Perhaps you could write up a small article that describes what sorts of
                    things you use timestamps for and how ISO8601 solved any problems or
                    concerns you had. It would make a good addition to the files section on
                    here I think.
                  • Bev MARKS (Mr)
                    All What a surprise to see this mail, which I thought had been lost in cyberspace, turn up 12 days later - it may have lost its impact in the thread
                    Message 9 of 16 , Jan 22, 2006
                      All

                      What a surprise to see this mail, which I thought had been lost in
                      cyberspace, turn up 12 days later - it may have lost its impact in
                      the thread therefore... (Let's see if this one arrives any quicker?)

                      Firstly I need to say the URL I quoted requires "/old.htm" to be
                      added, if you really want to look into the TPEG Project work. But as
                      challenged I am more than happy, in the next few weeks, to write a
                      short article to show how we use ISO 8601.

                      Bev

                      --- In ISO8601@yahoogroups.com, "piebaldconsult"
                      <PIEBALDconsult@a...> wrote:
                      >
                      > > Operating within Europe with two main time zones and co-ordinated
                      > > Summer Time changes we have experienced no particular problems
                      (over
                      > > several years) in our context of exchanging Traffic and Travel
                      > > Information Messages. At least all time processing is using the
                      same
                      >
                      > Yay! A happy customer. Go forth and spread the word!
                      >
                      > Perhaps you could write up a small article that describes what
                      sorts of
                      > things you use timestamps for and how ISO8601 solved any problems
                      or
                      > concerns you had. It would make a good addition to the files
                      section on
                      > here I think.
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.