Welcome to the NavList Message Boards.

NavList:

A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    Name or NavList Code:
    Email:
       
    Reply
    Re: leap seconds a navigational hazard, says expert
    From: Frederick Noon
    Date: 2003 Aug 11, 12:41 -0700

    Paul Hirose  writes:
    > This old message from 1988 indicates leap second bugs have occurred
    > many times. I'm not sure I believe that story about the French,
    > though.
    >
    > http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8801.mm.www/0022.html
    
    An excerpt from the above link:
    
      The earth's rotational poles wander over a roughly circular path
      every 14 months or so. This is caused by changes in the earth's mass
      distribution (solar tides, seasonal atmosphere mass shifts, melting
      snow caps, etc). The amplitude of the polar variation is roughly the
      size of a baseball diamond, and it causes small changes in the
      observer's true latitude and longitude -- therefore affecting the
      observer's astronomical observations on the order of 30 ms.
    
    This seems rather basic: does it mean that ones latitude and longitude
    isn't fixed, but wanders over this baseball diamond-sized area?  Are
    the latitude and longitude lines on a (relatively small-scaled) map
    the "average latitude" and "average latitude," or am I missing the
    point here?
    
    Btw., I'm not in the "time business" myself, but, as a programmer, I
    don't see the point of getting rid of UTC.  Sure, software can have
    bugs, but this proposal won't result in bug-free software: indeed, it
    will probably create confusion in the short-term.  Time is a
    complicated thing regardless, and (as another poster commented) the
    leap second business is probably the _easiest_ thing one needs to deal
    with (albeit it involves unpredictable, unforcastable elements that
    can't be precalculated to arbitrary points in the future).  The bottom
    line is that programmers should rigorously test such code, but often
    don't (for a variety of reasons).  It's the same story in other fields
    as well.
    
    There's a funny parallel to the Julian Calendar.  I'm an Orthodox
    Christian in a parish that uses the Julian Calendar for all liturgical
    purposes, but over the course of the 20th Century many jurisdictions
    went over to the Gregorian Calendar for most purposes (except the
    Paschal Cycle).  Now, Pope Gregory XIII thought he'd be stopping the
    procession of the equinoxes, and those Orthodox that originally made
    the change did so to promote Ecumenism, but the "common man's"
    argument these days among Orthodox "New Calendarists" seems to be that
    the Gregorian Calendar is simply "more accurate," because it better
    matches the Tropical Solar Year (as opposed to, say, the Sidereal Year
    or some such measurement).  The proposal to abandon UTC seems to go
    the other way: decouple time from the movement of the Earth.  I
    presume that the "common man" who would object to seeing his "Spring
    holiday" end up in the Fall (unless he changed hemispheres!) would
    also object to breakfast time ending up at midnight.  Granted, all
    this will take a *very* long time to become noticeable, but I think
    the principle should be considered: people in the modern West are used
    to an Earth-based time standard, and the "common man" wouldn't see
    much use in having anything else.  UTC seems to be a good compromise.
    *And* if it can upset the French holiday schedule, that's an added
    bonus! ;>
    
    (As I've said, I'm not in the "time business," so may have a few
    errors in my understanding of the workings here.  Actually, I'm not
    even in the "navigation business": I enjoy mathematical tinkering and
    measurment, and can go on vicarious sea voyages on this list without
    having to deal with salt water!)
    
    /Fredrik
    
    +-----------------------------------------------------------------+
    | Symeon            |  Fredrik Noon, Senior Software Engineer     |
    | fcn@noon.org      |  Hifn, Inc.                                 |
    | www.noon.org      |  fnoon@hifn.com +408/399-3630 (USA)         |
    |-------------------+---------------------------------------------|
    | pgp key:  DH/DSS 4093/1024:7840AC55 |
    | fingerprint: 5FB8 29B0 7F6D 24FA 6AD4  07E4 022E 0C58 7840 AC55 |
    +-----------------------------------------------------------------+
    
    
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Get a NavList ID Code

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.

    Retrieve a NavList ID Code

    Enter the email address associated with your NavList messages. Your NavList code will be emailed to you immediately.
    Email:

    Email Settings

    NavList ID Code:

    Custom Index

    Subject:
    Author:
    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site