Re: If this has been fixed, I haven't herd about it.
- You must communicate the scheduled timepoint in UTC.
If _you_ travel, _you_ must keep track of how that timepoint translates
in _your_ current timezone.
- --- In ISO8601@yahoogroups.com, hjwoudenberg@... wrote:
> If you schedule a time to call someone, and you take your cell
> appointment software to Europe, you will be reminded about a halfdozen hours to
> early. If you travel the world a big problem. If you travel theUS a
> smaller problem.standard.
> Fixing this problem is not big and is possible. The world needs a
>"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?
- 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.