Discussion in 'Ham Radio Discussions' started by N7BKV, Jun 10, 2019.
Stick with 3 letters for the month.
The way I've seen it when the military wrote orders for local time and considered DST they would call it Romeo+1 to compensate for the DST.
Three letters is probably better than two, but there's still the problem that they are English abbreviations, and potentially not useful to someone who doesn't speak English.
I sometimes use Roman numerals for the month, and this is apparently the convention some places. For example, 10-VI-2019 is unambiguously June 10.
Getting back to the original question, when dealing with hams, I usually just say 0130z, and I'm confident that they'll figure this out. For non-hams, I sometimes host conference calls where most of the callers are in the U.S.,but some are overseas. I'll usually express the time something like this, and hopefully this eliminates any confusion: "The Tuesday program begins at 7:00 PM U.S. Central Standard Time (Chicago time). For international callers, this is the same as 01:00 GMT Wednesday morning."
The schematic below has nothing to do with the topic. I accidentally uploaded it, and can't figure out how to get rid of it!
Actually, even the thread title is in error. UTC is UTC. No muss, no fuss, no trying to add + or -, or some letter. UTC is UTC.
And UTC time is redundant. It's saying "Universal Coordinated Time" time. HUH?
Well ... it depends. If there is already an understanding between the writer and reader that this is UTC (or any other timezone) then that's true, there is no need to specify a timezone for each entry. But ... if a datetime stands by itself and the reader might have some doubt then ... you need to specify the timezone.
I solve the problem by using Unix timestamps. They have no timezone.
Sorry, but UTC IS UTC. (Unless otherwise specified.) It does not matter if the sender and/or somehow understand otherwise. And a date ABSOLUTELY belongs to UTC, not ANY other "timezone" or UTC offset. UTC is UTC, period.
If I say I'll meet you at 09:15 then you need to ask me "what timezone?" unless you know that I only speak to you in UTC or some other agreed timezone.
If by this you mean a count of seconds since 00:00:00 UTC Jan 1 1970, they don't solve the problem.
UTC can't be represented as a simple integer count because of leap seconds. Every time one is introduced, the epoch jumps 1 second and all past events jump with it. Epochs by definition aren't supposed to do that. That was a major botch in the design of the UNIX kernel, and of all operating systems (e.g., Linux, OSX) that adopted it from UNIX.
Use TAI (international atomic time) or the GPS time scale. Neither follows leap seconds so they have a fixed relationship with each other. GPS time is probably easier to use since it's readily accessible from most GPS receivers, and the offset with UTC is always an integer number of seconds. The GPS epoch (January 6, 1980 at 00:00:00 UTC) occurred after all that nonsense with frequency adjustments and small jumps was removed from the UTC timescale (at the beginning of 1972, as I recall). TAI's epoch is in 1958, before UTC even formally existed, so the GPS-TAI difference has fractional seconds.
Okay, it's obviously more complicated than I realized.
in London (or Greenwich) midnight, it is STILL (currently) 5:00 PM the day BEFORE on the Left Coast.
That is what I was trying to say.
While UTC may be 0000, or 00:00, UTC, it is still 5:00 PM local ( currently West Coast CA) time. SO, tomorrow can still be today . THAT is why UTC must be used. for date AND time. My brother still uses a "24 hour" for local time, much to the admonitions of even family or his doctors. THEY are supposed to translate that 1800 is really 6:00 PM. Arrogance, I suppose. I (at least) can translate from 24 hour to AM/PM almost instantly and automatically. Practice makes perfect.