Is anyone importing Base.Dates.UTC

[Jeffrey Sarnoff]

from Base/Dates/types.jl

abstract TimeZone immutable UTC <: TimeZone end

If nobody has made use of this UTC typing, I advocate removing the line with UTC.

 

UTC signifies Universal Coordinated Time: [U]niversal [T]ime [C]oordinated is not the same as Universal Time, and both are used.  The 'C' is about international coordination of clocks and leap seconds.  Time zone attributed time, Zoned Time, is the time you see when unblanking your cell phone.  It is a regionally shifted, sometimes jumped way to value time.  A time zone is a named bundling of geopolitical boundaries with offsets given as minutes of displacement from UTC (or a leap-second-less surrogate) and, often, laws that establish when to observe Daylight Savings Time.

 

UTC is not a time zone.  If UTC were a time zone, then telling time would require already knowing it.

 

Forcing UTC to be share a concrete type with local times introduces an unhelpful typological fold. I am using UTC as a UTC time occurance constructor type; doing that decouples Dates a smidge, I'd rather it not.

[Steven G. Johnson]

Base.Dates.UTC seems to be used in the AWS, Elly, HttpCommon, and JavaCall packages.

[Jeffrey Sarnoff]

that is on point -- how did you search?

[Jacob Quinn]

Jeffrey,

Actually, UTC isn't exported, so there shouldn't be any naming conflicts, even when someone does `using Base.Dates`. That means you're free to define your own `UTC` and even export it and it won't conflict, because a person still has to do `Dates.UTC` to get the version in Base.

The usage in Base is extremely minimal. If it would make you feel better, we can just define it as `immutable UTC end` without subtyping `TimeZone`, but it's extremely common to talk about local times and timezones in relation to UTC (e.g. "+01 offset to UTC"); hence it makes sense in the single usage in Base (the `now()` function) to have a way to specify that the `DateTime` returned (which is timezone-unaware anyway) be according to UTC time vs. local time (i.e. whatever timezone is detected on the current system).

I don't think we're breaking any rules here, the usage is minimal, and it's not even exported, so I'm inclined to let it be.

-Jacob

[Jeffrey Sarnoff]

Jacob,

Yes, please do rewrite the defintion as `immutable UTC end`.

  Jeffrey

                               "I'll get by with a little help from .. " -- John & Paul, vocals

[Stefan Karpinski]

I don't know about this. It seems pretty standard to use UTC to refer to the UTC+0 time zone.

[Steven G. Johnson]

On Tuesday, August 11, 2015 at 8:16:50 PM UTC-4, Jeffrey Sarnoff wrote:

that is on point -- how did you search?

I have a little shell script that I use to fetch/update the master versions of all registered packages into a subdirectory on my machine, and then I can just grep for things:

#!/bin/sh

for f in ~/.julia/METADATA/*/url; do

    p=$(basename $(dirname $f))

    url=`cat $f`

    echo "updating $p from $url..."

    if test ! -d $p; then

        git clone $url $p

    else

        (cd $p; git pull origin master)

    fi

done 

[Jacob Quinn]

I agree Stefan. It's almost like there's a pretty standard dual meaning to "UTC"; in one sense and context, is the manner of tracking time (bridging UT1 & TAI), in another sense and context (i.e. relating to other timezones), it's the "zero offset" timezone, or the frame of reference that all other timezones are based off.

-Jacob

[Jeffrey Sarnoff]

I have no problem with your logic -- my request is definition driven.  The connection being drawn from UTC time to local timezone time is not supported by the way these things are defined.   All local times, the time-in-timezone sort of times are "civil times", times for civilian use and their is much international law that enshrines this.  Timezone times are developed as offsets from a time at the prime meridian, that time is not UTC. It is the long standing civil time that used to be given as GMT.  UTC, TAI and others are "scientific times" and UTC right now is easily approximated, but not actually available right now.  Civil time at the meridian is available right now, and local times are shifted from that  because they need to be known in the present.

As you introduce more flavors of time, e.g. gps time, earth-moon barycentric time for satellite management, small imprecisions make pervasively correct results very difficult to obtain and require less transparent designs.

[Chris Foster]

On Thu, Aug 13, 2015 at 8:01 AM, Jeffrey Sarnoff <jeffrey...@gmail.com> wrote:

Timezone times are developed as offsets from a time at the prime meridian, that time is not UTC. It is the long standing civil time that used to be given as GMT.  UTC, TAI and others are "scientific times" and UTC right now is easily approximated, but not actually available right now.

This seems to be a rather subtle point - would you mind expanding further?  As I understand it, UTC is simply TAI minus the current number of leap seconds, which is certainly computable right now.  Is there something more complicated going on?

~Chris

[Jeffrey Sarnoff]

Happy to do so.  Yes, there is more to this than one usually sees. That is, in part, by design.  The rules that allow one time flavor to be obtained from some philosopically different other by adding a constant -- let data be processed and spaceships fly.  Except for rare occasions; when a critical security system siezes up by watching itself incessantly or targeting adjustments to a new missile system do not compensate for inaccuracies.  

In 2011, at an open meeting about satellites a representative from an international time standards group put up a slide that included this bullet point:

"UTC, as published today, is not adapted for real and quasi-real time applications," (I will explain why in my next post).

[Jeffrey Sarnoff]

There was a New Year's Eve party on 1969-Dec-31 at the (then so named)

Royal Greenwich Observatory. And the caretakers of the world's most

respected UTC clock are watching it, counting down seconds to 1970:

"three, two, one .. (cheers, hugs and kisses)"

                    ^

                    right there then, what time was it?

I'll assume you answered 1970-Jan-01 00:00:00 UTC.  And that is precisely

the time they heard the peal of champagne glass touching, well-wishing.

(once more: it was just so and that answer is wrong.)  

All times in UTC that predate 1972-Jan-01 00:00:00 UTC are expressions of

something that is not of qualitative sameness nor readily commensurable.

They first embrace at 1969-Dec-31 23:59:58 UTC.  That is the time that

they had witnessed as 1970-Jan-01 00:00:00 UTC.

Taking time's measure is different from telling time.

-----

UTC is not now and never has been time on a clock -- so reading the

"Master Clock" that is kept under guard at the US Navel Observatory

reads an accomplished approximation to UTC designated by UTC(USNO).

NIST's Physical Measurement Laboratory maintains the Clock NIST-F1;

it is the primary US standard for time and frequency. Reading this

clock gives an accomplished approximation to UTC designated UTC(NIST).

The times reported by UTC(USNO) and UTC(NIST) are not identical. These

are two clocks that report times that are quite close, not identical.

During 2015, using 1 x uncertainty reported, each has been within

~25 nanoseconds of the other and ~30 nanoseconds out of sync with

the the canonical solution for UTC as later reported.

UTC obtains from a weighting of values posited by, say six most senior

and, say another fifty international standards bureau's  atomic clocks.

(more are used, some of the weights are almost lights).  Most keep to

within 100 nanoseconds of UTC.  And this that is the third of three

staged processes that result in the hindsight driven solving for UTC.

The real time unavailability of UTC is not an artifact of definition,

UTC is designed to be the world's source for stable, reliable time.

That is possible only with methods that operate retrospectively.

[Nehal Patel]

This is quite interesting....

So is the process of computing/producing UTC something like the following?

++ Periodically, at the same physical "instant", several (50-100) clocks around the world report their time to an observer (e.g. a computer server somewhere).  If so, Question #1, how in the world is that technically possible to do accurately? (laser links ala Einstein?)  Question #2, With accuracy on the order of nanoseconds, and the clocks are on different parts of a spinning earth, do relativistic limits on simultaneity come into play?

++ After collecting data, "computing UTC" essentially means producing an inverse mapping to all the other clocks e.g.  deciding the  timestamp of UTC 1,000,000,000,000 corresponds to    UTC(USNO) 1,000,000,000,001 and 999,999,999,993  UTC(NIST), etc

perhaps off topic but useful to understand when designing a time library for technical computing...

Thanks, Nehal

[ggggg]

I'm not an expert, what I'll add comes from reading a few wikipedia articles. The wikipedia articles on UTC and TAI appear to be pretty good. As I understand it, the various national measurement institute compares their clocks more or less continuously by simultaneously observing GPS signals. There is also a more precise two way satellite time transfer technique that is used. There is a monthly publication that provides the information necessary to convert a timestamp in other timescales such as UTC(USNO) (the real time approximation to UTC provided by the US naval observatory) to TAI or UTC with maximum precision. I think Jeffrey's key concern is "UTC, TAI and others are "scientific times" and UTC right now is easily approximated, but not actually available right now." But in order to ever convert to UTC with maximum precision, you need to start with a timescale in the monthly publication, or be able to convert to one. So probably the vast majority of uses of Base.Dates will not ever be able to convert to UTC with any higher precision than they can currently estimate it, even in retrospect.

While UTC is not a time zone, time zones are generally defined as a fixed time offset (generally in hours or half hours) from UTC. So the use case of UTC as a timezone seems consistent with definition. Wikipedia says the time zone using UTC is sometimes called UTC±00:00 or Z. 

[Jeffrey Sarnoff]

The time we use to coordinate dinner with a friend is the same as the time nations use when they agree to cease hostilities. The community likes UTC.

You are adopting twins and have given them then a single name.

The community would benefit from a well-structured, highly peformant, and

dispach-levered way to ascertain which of one the them is active

with the means for their efficient and seperate direction.

[Jeffrey Sarnoff]

The time we use to coordinate dinner with a friend is the same as the time nations 

use when they agree to cease hostilities. The community likes UTC.

You are adopting twins and have given them then a single name.  You may find

benefit from a well-structured, highly peformant, and dispatch-levered way 

to ascertain which of one the them is active with the means for their efficient

and separate direction.

[Jeffrey Sarnoff]

Nehal,

Yes relativity is felt.  The way UTC is determined the empahsis for any center of metroloty is to get theirlocal compensating and uncertainty reduced house in ever better order.  There i a great deal of pre-design planning that goes as much to  the nature of clockbuilding as it does to the quieting or cataloguing of their very local graviometrric enivronment.  a cell phone charger plugged in to an outlet on another floor could inroduce just enough fuzz and skrakel to cause misreading.  Ther have been cases where deliveries made to a business that coudl not bee seen or heard from the lab were determined to be the cause of very low and intermittant vibrations that shut things down for a week or more.  

 relativistic? absolutely. 

"Our performance means that we can measure the gravitational shift when you raise the clock just 2 centimeters on the Earth's surface," JILA/NIST Fellow Jun Ye

The way UTC resolves to a fit does not expect the world to sit quietly every  ~fifth day for their data colleection.  Someone was thinking ahead.

Thank you for the interest -- it is not off topic , someone of us needs to be readying "Julia's sub-attosecond stride."

[Chris Foster]

Hi Jeffery,

Thanks for expanding a bit. It makes sense that measuring time with a
real physical device always involves some uncertainty, but I hadn't
thought about the "Coordinated" in UTC and what it means for the
realtime availability.

I think I see why having UTC be a TimeZone is undesirable from your
point of view, but I'd like to understand some more of the background.
Do you have some recommended reading regarding the official
standards-based definition of UTC? At a first glance there's a lot of
confusion on the web and it takes some digging to get anything useful.
So far I've found the ITU-R Recommendation 460
(https://www.itu.int/rec/R-REC-TF.460/en), and some nice articles from
a colloquium "Decoupling Civil Timekeeping from Earth Rotation"
http://www.cacr.caltech.edu/futureofutc/2011/preprints/index.html,
including the introduction
http://www.cacr.caltech.edu/futureofutc/2011/preprints/01_AAS_11-660.pdf
.

On Sun, Aug 16, 2015 at 3:26 AM, Jeffrey Sarnoff
<jeffrey...@gmail.com> wrote:
> relativistic? absolutely.
> "Our performance means that we can measure the gravitational shift when you
> raise the clock just 2 centimeters on the Earth's surface," JILA/NIST Fellow
> Jun Ye

For anyone interested, the original paper describing this result is here:
http://www.nature.com/ncomms/2015/150421/ncomms7896/pdf/ncomms7896.pdf
with some nice commentary here:
http://www.nist.gov/pml/div689/20140122_strontium.cfm

This is a clock locked to an optical transition of an ultracold cloud
of Strontium atoms trapped in an optical lattice, with systematic
errors very carefully calibrated. It provides much better stability
than clocks locked to the cesium transition currently used in the
definition of the SI second.

I have an interest in accurate timekeeping in Julia because I deal
with geospatial sensor data from a lot of different device
manufacturers. The logging of timestamps with carefully defined
semantics is often not great, even when connected to high quality GPS
equipment.

~Chris

[Jeffrey Sarnoff]

Chris,

Good job finding where I first read “UTC without leap seconds"  

(the paper has these 15 words and says them over and over):

      "the future of civil timekeeping 

           should not hinge on the anticipated

                  incompetence of some programmers"

( History of Time and Leap seconds, P. Kenneth Seidelmann )

( Scales of Time, B. Guinot, metrologia )

( Is Time's Arrow Perspectival? Carlo Rovelli arXiv:1505.01125v2 [physics.hist-ph] 10 May 2015)

[Vocabulary for Time Scales](http://www.cacr.caltech.edu/futureofutc/preprints/files/13_AAS%2013-507_Redman.pdf)

[Representation of Time in FITS](http://www.researchgate.net/profile/Mark_Calabretta/publication/266204427_Representations_of_Time_Coordinates_in_FITS/links/55b718a408ae9289a08bd03c.pdf_

[Time in the 10,000 Year Clock](http://www.cacr.caltech.edu/futureofutc/2011/preprints/10_AAS_11-665_Hillis.pdf)

[ISO statement on terminology](http://www.cacr.caltech.edu/futureofutc/preprints/files/10_AAS%2013-506_Finkleman.pdf)

( IAU 2006 Resolution B3 )

( Rev Mod Phys Vol 78 No 4 Oct-Dec 2006 John L Hall Nobel Lecture 

    1 1/2 pages of the section on Clocks and Time ( mid 1281 - top 1283 ) )

( Glossary of Time Granularity Concepts Claudio Bettini .. Richard T. Snodgrass .. )

[Legislation and Universal Time](http://www.cacr.caltech.edu/futureofutc/2011/preprints/04_AAS_11-662_Seago.pdf)

[only the penultimate paragraph on page 2](http://www.cacr.caltech.edu/futureofutc/preprints/files/14_AAS%2013-507discussion.pdf)

[Symbolism and Expediency](http://www.cacr.caltech.edu/futureofutc/2011/preprints/06_AAS_11-663_Gabor.pdf)

enjoy and let me know your then perspective

Jeffrey

[Jeffrey Sarnoff]

Please use this thread  now. 

[Jeffrey Sarnoff]

            Please use this thread going forward.

[Jeffrey Sarnoff]

icing on the cake, or just cake

and every paper by Bernard Guinot

Ephemeris Time, relativity, and the problem of uniform time in astronomy

Authors: Winkler, G. M. R. & van Flandern, T. C.

Journal: Astronomical Journal, vol. 82, Jan. 1977, p. 84-92.

[IAU Resolutions on Astronomical Reference Systems, Time Scales, ,,s](http://arxiv.org/abs/astro-ph/0602086)

Title: Relativistic time scales in the solar system

Authors: Brumberg, V. A. & Kopeikin, S. M.

Journal: Celestial Mechanics and Dynamical Astronomy (ISSN 0923-2958), vol. 48, no. 1, 1990, p. 23-44.

nuary 2012

[Legal Traceablility of TIme](http://tf.nist.gov/general/pdf/1433.pdf)

#30#

On Wednesday, August 19, 2015 at 12:14:04 AM UTC-4, Jeffrey Sarnoff wrote: