Re: If this has been fixed, I haven't heard about it.
- Hi there,
Very good points. I considered this issue at some length when
designing the time subsystem on the NxtPhase Relays and Recorders some
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
3. Display format and frame of reference for user
Users want to display in their own format, with Daylight Savings,
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.
--- In ISO8601@yahoogroups.com, hjwoudenberg@... wrote:
> If you schedule a time to call someone, and you take your cell phone
> 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.
> 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!
- --- In ISO8601@yahoogroups.com, "piebaldconsult" <PIEBALDconsult@...>
> > ONLY EXACTLY on (actual local) time, ANYwhere in the world!
> Yes, but... time zone isn't strictly decided by location on the
> 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.)
> 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 andI think my point may have been that you can't go directly from GPS-to-
> 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.
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 implementedRight, I understand Antarctic stations use Z or something (their
> correctly might still exist, of course there only Z is applicable.)
national offset?), but I could be very wrong.