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

Dates with timezone information

Expand Messages
  • mattias_flodin
    Hello, I am trying to follow the ISO 8601 requirements for date and time formatting in an application where I need to store a date, and am completely
    Message 1 of 16 , Jan 5, 2006
    • 0 Attachment
      Hello,

      I am trying to follow the ISO 8601 requirements for date and time
      formatting in an application where I need to store a date, and am
      completely dumbfounded by the lack of information on representing the
      time zone together with the date.

      As far as I can tell, there are two possible ways of extrapolating the
      rules for representation of time zone bias:
      A. Put the time zone directly after the date: 2000-01-02+03:04.
      B. Use a 'T' separator before the time zone: 2000-01-02T+03:04.

      Alternative A has a problem with ambiguity. Take for example the
      string "2000-01-02:03". This could be interpreted as either "Year
      2000, January 2nd, 3 am" or "Year 2000, January, time zone bias
      negative 2 hours 3 minutes".

      Alternative B essentially becomes a combined date and time, so it
      would have to adhere to the rules for such combinations. Because of
      that, it becomes impossible to use reduced precision in dates that
      have time zone information. For example, "2000T+01:02" is illegal
      according to the rules in the standard.

      Is it possible that the need to represent dates with time zone
      information has been overlooked by the standardization group? If not
      how should this situation be handled?

      Thanks in advance,
      Mattias Flodin
    • NGUYEN Ivy
      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
      Message 2 of 16 , Jan 5, 2006
      • 0 Attachment
        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.

        On 05/01/06, mattias_flodin <flodin@...> wrote:
        > Hello,
        >
        > I am trying to follow the ISO 8601 requirements for date and time
        > formatting in an application where I need to store a date, and am
        > completely dumbfounded by the lack of information on representing the
        > time zone together with the date.
        >
        > As far as I can tell, there are two possible ways of extrapolating the
        > rules for representation of time zone bias:
        > A. Put the time zone directly after the date: 2000-01-02+03:04.
        > B. Use a 'T' separator before the time zone: 2000-01-02T+03:04.
        >
        > Alternative A has a problem with ambiguity. Take for example the
        > string "2000-01-02:03". This could be interpreted as either "Year
        > 2000, January 2nd, 3 am" or "Year 2000, January, time zone bias
        > negative 2 hours 3 minutes".
        >
        > Alternative B essentially becomes a combined date and time, so it
        > would have to adhere to the rules for such combinations. Because of
        > that, it becomes impossible to use reduced precision in dates that
        > have time zone information. For example, "2000T+01:02" is illegal
        > according to the rules in the standard.
        >
        > Is it possible that the need to represent dates with time zone
        > information has been overlooked by the standardization group? If not
        > how should this situation be handled?
        >
        > Thanks in advance,
        > Mattias Flodin
      • piebaldconsult
        Indeed, it wouldn t make sense. And dates do _not_ allow for a time zone. If you mean to indicate the entire day, use a time interval. But if it s just for you
        Message 3 of 16 , Jan 5, 2006
        • 0 Attachment
          Indeed, it wouldn't make sense. And dates do _not_ allow for a time
          zone.

          If you mean to indicate the entire day, use a time interval.

          But if it's just for you (no interchange), you can do what you want.
        • Stephen GOULD
          18:22 Fri 06 Dec 2006 REF:AECSTFN1 Y/R: ISO8601 Timezones TO: ISO8601 Special Interest Group cc ebXML Developers Hi - Happy New Year INCORPORATING
          Message 4 of 16 , Jan 6, 2006
          • 0 Attachment
            18:22 Fri 06 Dec 2006 REF:AECSTFN1
            Y/R: ISO8601 Timezones

            TO: ISO8601 Special Interest Group cc ebXML Developers

            Hi - Happy New Year

            INCORPORATING TIMEZONES AS PART OF ISO8601

            ISO 8601 was first released in 1988 - 18 years ago.

            Yet this is the first e-mail I have seen in the last 3 years that supports
            our submission in 2002 that ISO 8601 can not operate as an integrated
            function of the automated business process unless Timezones are
            incorporated as part of ISO 8601

            Can we see if we can resolve this issue for Matthius in 2006 as this
            is a critical issue for eCommerce and International Trade ?

            It is a very important aspect for Electronic Tenders particularly
            as many of the bi-lateral Free Trade Agreements focus on
            Government tenders.
            http://www.oic.org/z/FZIG

            In Australia we have 3 different time zones with 2 different Day-light
            saving rules on the East Coast in the same time zone

            Most tenders have at least 3 key Date & Time fields that are influenced
            by the Time Zone.

            1 Tender Response Date & Time
            2 Tender Question Registration Date & Time
            3 Tender Briefing Registration Date & Time

            Global Position Systems can be fitted to any PC to identify exactly
            where that PC is located.
            eg Delorme Earthmate
            http://www.delorme.com/earthmatelt20/default.asp

            Microsoft Windows automatically updates the computer clock
            for daylight saving

            So surely we can devise an acceptable format to include a timezone
            as part of the ISO 8601 Date format.

            I would be prepared to act as the co-ordinator for an ISO8601-Timezone
            WorkGroup.

            I would propose that it is set up along the same lines as those used
            by the ebXML Australia Marketing Work Group
            http://www.oic.org/EB/

            There would be:

            A A plan with stages and timetable
            B A clearly defined objective of the WorkGroup
            C All e-mail responses placed on a web-site rather than left
            as e-mails

            PROPOSED OBJECTIVE

            To define a format for the Time Zone and local Daylight Savings rules
            to be incorporated into ISO8601 by 31 Dec 2006

            NEXT STEPS

            Please advise

            1 who would be prepared to be involved in the WorkGp ?

            2 Any changes to the objectives ?

            3 If we should use a BBS like godlikeproductions.com to
            provide a thread of all the e-mails ?

            Here is an example of an "Anomalous World-wide Tectonic Event
            on 03 Jan 2006"

            http://www.godlikeproductions.com/bbs/message.php?page=1&showdate=1/6/06
            &messageid=196706&mpage=1


            Regards

            Stephen GOULD
            Chair
            OIC XML & eCommerce Special Interest Group
            OPEN INTERCHANGE CONSORTIUM
            21:19 F 2005/01/06 Syd 2065

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

            On 6 Jan 06, at 3:41, piebaldconsult wrote:

            > Indeed, it wouldn't make sense. And dates do _not_ allow for a time
            > zone.
            >
            > If you mean to indicate the entire day, use a time interval.
            >
            > But if it's just for you (no interchange), you can do what you want.
            >
            >
            >
            On 5 Jan 06, at 11:30, mattias_flodin wrote:

            > Hello,
            >
            > I am trying to follow the ISO 8601 requirements for date and time
            > formatting in an application where I need to store a date, and am
            > completely dumbfounded by the lack of information on representing the
            > time zone together with the date.
            >
            > As far as I can tell, there are two possible ways of extrapolating the
            > rules for representation of time zone bias:
            > A. Put the time zone directly after the date: 2000-01-02+03:04.
            > B. Use a 'T' separator before the time zone: 2000-01-02T+03:04.
            >
            > Alternative A has a problem with ambiguity. Take for example the
            > string "2000-01-02:03". This could be interpreted as either "Year
            > 2000, January 2nd, 3 am" or "Year 2000, January, time zone bias
            > negative 2 hours 3 minutes".
            >
            > Alternative B essentially becomes a combined date and time, so it
            > would have to adhere to the rules for such combinations. Because of
            > that, it becomes impossible to use reduced precision in dates that
            > have time zone information. For example, "2000T+01:02" is illegal
            > according to the rules in the standard.
            >
            > Is it possible that the need to represent dates with time zone
            > information has been overlooked by the standardization group? If not
            > how should this situation be handled?
            >
            > Thanks in advance,
            > Mattias Flodin
          • piebaldconsult
            ... supports ... JYIS Timezones _are_ supported. You can have an offset from UTC specified down to the minute, which ought to be more than enough precision.
            Message 5 of 16 , Jan 6, 2006
            • 0 Attachment
              > Yet this is the first e-mail I have seen in the last 3 years that
              supports
              > our submission in 2002 that ISO 8601 can not operate as an integrated
              > function of the automated business process unless Timezones are
              > incorporated as part of ISO 8601

              JYIS

              Timezones _are_ supported. You can have an offset from UTC specified
              down to the minute, which ought to be more than enough precision. What
              you mean by a particular offset is up to you and your partners in
              interchange.
            • piebaldconsult
              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
              Message 6 of 16 , Jan 6, 2006
              • 0 Attachment
                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.
              • 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 7 of 16 , Jan 6, 2006
                • 0 Attachment
                  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
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                • Stephen GOULD
                  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
                  Message 8 of 16 , Jan 7, 2006
                  • 0 Attachment
                    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@...
                    W: http://www.oic.org/z/XZIG/A/
                  • 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 9 of 16 , Jan 7, 2006
                    • 0 Attachment
                      > 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 10 of 16 , Jan 8, 2006
                      • 0 Attachment
                        --- 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 11 of 16 , Jan 14, 2006
                        • 0 Attachment
                          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 12 of 16 , Jan 14, 2006
                          • 0 Attachment
                            --- 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 13 of 16 , Jan 15, 2006
                            • 0 Attachment
                              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 14 of 16 , Jan 15, 2006
                              • 0 Attachment
                                > 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 15 of 16 , Jan 20, 2006
                                • 0 Attachment
                                  > 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 16 of 16 , Jan 22, 2006
                                  • 0 Attachment
                                    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.