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

Re: If this has been fixed, I haven't herd about it.

Expand Messages
  • piebaldconsult
    You must communicate the scheduled timepoint in UTC. If _you_ travel, _you_ must keep track of how that timepoint translates in _your_ current timezone.
    Message 1 of 7 , Jul 8, 2007
      You must communicate the scheduled timepoint in UTC.

      If _you_ travel, _you_ must keep track of how that timepoint translates
      in _your_ current timezone.
    • datefreak
      ... phone or ... dozen hours to ... US a ... standard. ... The world HAS that necessary standard. It s called: ISO 8601. In that standard, both UTC and Z
      Message 2 of 7 , Jul 8, 2007
        --- In ISO8601@yahoogroups.com, hjwoudenberg@... wrote:
        >
        > If you schedule a time to call someone, and you take your cell
        phone or
        > appointment software to Europe, you will be reminded about a half
        dozen hours to
        > early. If you travel the world a big problem. If you travel the
        US a
        > smaller problem.
        >
        > Fixing this problem is not big and is possible. The world needs a
        standard.
        >

        "The world" HAS that necessary standard. It's called: ISO 8601.
        In that standard, both UTC and Z have been defined well enough. And
        combined with GPS, that would do the trick completely.
        Because then, the second part of my statement (which you forgot to
        emphasize) comes in. If UTC and GPS data will be combined in all
        appliances concerned, you NEVER would be reminded early or late, but
        ONLY EXACTLY on (actual local) time, ANYwhere in the world!

        This very simple solution has been known for quite a lot of decades
        already, and has been strongly advocated since by a vast majority of
        right-thinking people. Only problem is: both Government AND Industry,
        because of reasons obscure being reluctant to accept AND consequently
        actually implement it within reasonable time.
        That's a well known world wide general problem. Just think about why
        this discussion group origionally has been started for: the actual
        universal integral implementation of ISO 8601 .....

        > The other stuff makes the problem big.

        What stuff do you refer to?

        Regards,
        Jan
      • piebaldconsult
        ... Yes, but... time zone isn t strictly decided by location on the globe, there are other factors.
        Message 3 of 7 , Jul 14, 2007
          > ONLY EXACTLY on (actual local) time, ANYwhere in the world!

          Yes, but... time zone isn't strictly decided by location on the globe,
          there are other factors.
        • dmweiten
          Hi there, Very good points. I considered this issue at some length when designing the time subsystem on the NxtPhase Relays and Recorders some years ago. I
          Message 4 of 7 , Jul 15, 2007
            Hi there,

            Very good points. I considered this issue at some length when
            designing the time subsystem on the NxtPhase Relays and Recorders some
            years ago.

            I saw three issues:
            1. The format and frame of reference for time sync source
            We used IRIG-B signal source, often local time, sometimes
            with Daylight Savings, often without. Sometimes with IEEE-1344
            extensions so it would tell us what the offset was, often
            without. What drove me crazy was when they said there was no
            DST but then you get an hours' jump at the DST shift time.
            2. System's internal representation and frame of refence of time
            This was always UTC. Our devices were intended for wide area
            power systems disturbance analysis, so it facilitated
            records' interchange.
            3. Display format and frame of reference for user
            Users want to display in their own format, with Daylight Savings,
            etc.

            Some users, unfortunately, didn't \understand or care, and set all
            offsets to zero. Then they wondered why things were screwed up :-<

            Perhaps I / we didn't do a good job of explaining it to them.

            Dean Weiten.


            --- In ISO8601@yahoogroups.com, hjwoudenberg@... wrote:
            >
            > If you schedule a time to call someone, and you take your cell phone
            or
            > appointment software to Europe, you will be reminded about a half
            dozen hours to
            > early. If you travel the world a big problem. If you travel the US a
            > smaller problem.
            >

            <chop chop>

            > It would be nice if every watch, computer, cell phone, electric oven,
            > car or whatever hardware, internally as well as for interchange only
            > would use a Universal Atomic Second Number (kind of UTC measured in
            > seconds) being transmitted continuously, and would give it's user the
            > opportunity to make it convert that to any calendar of his own choice
            > and show that on the display, using GPS to calculate correct Z .....
            >
            > THAT would really ease things up and facilitate simple formulas!

            <chop chop>
          • datefreak
            ... globe, ... What other factors? Time zone is not defined in ISO 8601. Actual time shift between local (or standard) time and UTC is. And there, GPS comes
            Message 5 of 7 , Aug 10, 2007
              --- In ISO8601@yahoogroups.com, "piebaldconsult" <PIEBALDconsult@...>
              wrote:
              >
              > > ONLY EXACTLY on (actual local) time, ANYwhere in the world!
              >
              > Yes, but... time zone isn't strictly decided by location on the
              globe,
              > there are other factors.
              >

              What other factors?

              Time zone is not defined in ISO 8601. Actual time shift between local
              (or standard) time and UTC is.

              And there, GPS comes in.
              With ISO 8601 implemented correctly by locally competent authorities,
              for ANY spot in the world the time difference between local time and
              UTC is known at ANY moment, all discontinuities in local time scale
              accounted for. Thus, Z and GPS data combined, it should be simple to
              show correct actual local time there and then.

              (If very rare "black spots" where ISO 8601 might not be implemented
              correctly might still exist, of course there only Z is applicable.)

              Regards,
              Jan
            • piebaldconsult
              ... (So tempted... so tempted...) ... I think my point may have been that you can t go directly from GPS-to- offset, you ll need some sort of lookup table
              Message 6 of 7 , Aug 24, 2007
                > With ISO 8601 implemented correctly by locally competent authorities,

                (So tempted... so tempted...)


                > for ANY spot in the world the time difference between local time and
                > UTC is known at ANY moment, all discontinuities in local time scale
                > accounted for. Thus, Z and GPS data combined, it should be simple to
                > show correct actual local time there and then.

                I think my point may have been that you can't go directly from GPS-to-
                offset, you'll need some sort of lookup table (which must be kept
                updated) of GPS-to-region because time zone lines wander and such.


                > (If very rare "black spots" where ISO 8601 might not be implemented
                > correctly might still exist, of course there only Z is applicable.)

                Right, I understand Antarctic stations use Z or something (their
                national offset?), but I could be very wrong.
              Your message has been successfully submitted and would be delivered to recipients shortly.