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

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

Expand Messages
  • 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 1 of 7 , Jul 15, 2007
    • 0 Attachment
      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 2 of 7 , Aug 10, 2007
      • 0 Attachment
        --- 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 3 of 7 , Aug 24, 2007
        • 0 Attachment
          > 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.