Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #145753

Re: "C++: Size Matters in Platform Compatibility"

Show all headers | View raw

On Wednesday, August 21, 2019 at 10:05:12 PM UTC+3, Scott Lurndal wrote:
> Eli the Bearded <*@eli.users.panix.com> writes:
> >In comp.lang.c, Bonita Montero  <Bonita.Montero@gmail.com> wrote:
> >> I prefer Win32's FILETIME which is a 64 bit integer that
> >> counts the number of 100ns-steps since 1.1.1601 00:00.
> >
> >First thing I think of when I see that is "In what calendar?" Gregorian
> >transition started in 1582, happend in Britain and it's colonies in
> >1752, and I think you have to get to 1923 for Europe to finish switching
> >from Julian. (Greece was 1923, Turkey was 1926.)
> >
> >> Unfortunately that's not portable.
> >
> >Yes. Julian is still drifting apart at a rate of 1 day per 400 years,
> >which is around 0.0016 seconds day. That's a big jump in nanoseconds.
> >
> >Elijah
> >------
> >given MS, probably whatever calender Redmond was on in 1995
> >
> 
> Starting dates are completely arbitrary, and no one is better than the
> other.  Personally, a 64-bit unix time_t works just fine.
> 

1sec resolution is almost never sufficient for my purposes.
0.1usec on the other hand is sufficient for everything I do except profiling.
Something like 1usec would also be sufficient for everything except profiling, but I don't really feel that range of 290,000 years is much better than 29,000 years. Both ranges are insufficient for everybody and everything, but sufficient for almost everybody and almost everything and certainly for my "real work".
 

> 
> http://www3.sympatico.ca/n.rieck/docs/calendar_time_y2k_etc.html#vax_vms_time
> 
> QUESTION:
> 
> Why is Wednesday, November 17, 1858 the base time for OpenVMS (VAX VMS)?
> 
> ANSWER:
> 
> November 17, 1858 is the base of the Modified Julian Day system.
> 
> The original Julian Day (JD) is used by astronomers and expressed in
> days since noon January 1, 4713 B.C.  This measure of time was
> introduced by Joseph Scaliger in the 16th century.  It is named in
> honor of his father, Julius Caesar Scaliger (note that this Julian Day
> is different from the Julian calendar named for the Roman Emperor
> Julius Caesar!).
> 
> Why 4713 BC?  Scaliger traced three time cycles and found that they
> were all in the first year of their cyle in 4713 B.C.  The three
> cycles are 15, 19, and 28 years long.  By multiplying these three
> numbers (15 * 19 * 28 = 7980), he was able to represent any date from
> 4713 B.C. through 3267 A.D.  The starting year was before any
> historical event known to him.  In fact, the Jewish calendar marks the
> start of the world as 3761 B.C.  Today his numbering scheme is still
> used by astronomers to avoid the difficulties of converting the months
> of different calendars in use during different eras.
> 
> So why 1858?  The Julian Day 2,400,000 just happens to be November 17,
> 1858.  The Modified Julian Day uses the following formula:
> 
>      MJD = JD - 2,400,000.5
> 
> The .5 changed when the day starts.  Astronomers had considered it
> more convenient to have their day start at noon so that nighttime
> observation times fall in the middle.  But they changed to conform to
> the commercial day.
> 
> The Modified Julian Day was adopted by the Smithsonian Astrophysical
> Observatory (SAO) in 1957 for satellite tracking.  SAO started
> tracking satellites with an 8K (non-virtual) 36-bit IBM[R] 704 computer
> in 1957, when Sputnik was launched.  The Julian day was 2,435,839 on
> January 1, 1957.  This is 11,225,377 in octal notation, which was too
> big to fit into an 18-bit field (half of the IBM standard 36-bit word).
> And, with only 8K of memory, no one wanted to waste the 14 bits left
> over by keeping the Julian Day in its own 36-bit word.  However, they
> also needed to track hours and minutes, for which 18 bits gave enough
> accuracy.  So, they decided to keep the number of days in the left 18
> bits and the hours and minutes in the right 18 bits of a word.
> 
> Eighteen bits would allow the Modified Julian Day (the SAO day) to
> grow as large as 262,143 ((2 ** 18) - 1).  From Nov. 17, 1858, this
> allowed for seven centuries.  Using only 17 bits, the date could
> possibly grow only as large as 131,071, but this still covers 3
> centuries, as well as leaving the possibility of representing negative
> time.  The year 1858 preceded the oldest star catalog in use at SAO,
> which also avoided having to use negative time in any of the satellite
> tracking calculations.
> 
> This base time of Nov. 17, 1858 has since been used by TOPS-10,
> TOPS-20, and VAX VMS and OpenVMS.  Given this base date, the 100
> nanosecond granularity implemented within OpenVMS and the 63-bit
> absolute time representation (the sign bit must be clear), OpenVMS
> should have no trouble with time until:
> 
>      31-JUL-31086 02:48:05.47
> 
> At this time, all clocks and time-keeping operations in OpenVMS will
> suddenly stop, as system time values go negative.
> 
> Note that the OpenVMS time display and manipulation routines allow for
> only 4 digits in the 'YEAR' field.  We expect this to be corrected in
> a future release of OpenVMS sometime prior to 31-DEC-9999.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

"C++: Size Matters in Platform Compatibility" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-16 14:04 -0500
  Re: "C++: Size Matters in Platform Compatibility" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-16 20:45 +0000
    Re: "C++: Size Matters in Platform Compatibility" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-08-16 15:38 -0700
  Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-17 15:08 +0200
    Re: "C++: Size Matters in Platform Compatibility" Geoff <geoff@invalid.invalid> - 2019-08-17 12:43 -0700
      Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-18 12:32 +0200
        Re: "C++: Size Matters in Platform Compatibility" Geoff <geoff@invalid.invalid> - 2019-08-18 13:10 -0700
          Re: "C++: Size Matters in Platform Compatibility" Bart <bc@freeuk.com> - 2019-08-18 21:15 +0100
          Re: "C++: Size Matters in Platform Compatibility" Keith Thompson <kst-u@mib.org> - 2019-08-18 14:49 -0700
            Re: "C++: Size Matters in Platform Compatibility" Keith Thompson <kst-u@mib.org> - 2019-08-18 14:51 -0700
          Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-19 08:43 +0200
            Re: "C++: Size Matters in Platform Compatibility" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-19 09:15 +0200
      Re: "C++: Size Matters in Platform Compatibility" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-21 17:14 +0200
        Re: "C++: Size Matters in Platform Compatibility" Eli the Bearded <*@eli.users.panix.com> - 2019-08-21 18:30 +0000
          Re: "C++: Size Matters in Platform Compatibility" scott@slp53.sl.home (Scott Lurndal) - 2019-08-21 19:05 +0000
            Re: "C++: Size Matters in Platform Compatibility" already5chosen@yahoo.com - 2019-08-21 14:10 -0700
          Re: "C++: Size Matters in Platform Compatibility" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-21 21:25 +0200
          Re: "C++: Size Matters in Platform Compatibility" Keith Thompson <kst-u@mib.org> - 2019-08-21 12:28 -0700
          Re: "C++: Size Matters in Platform Compatibility" Richard Damon <Richard@Damon-Family.org> - 2019-08-22 22:58 -0400
            Re: "C++: Size Matters in Platform Compatibility" Eli the Bearded <*@eli.users.panix.com> - 2019-08-23 19:15 +0000
    Re: "C++: Size Matters in Platform Compatibility" Anton Shepelev <anton.txt@gmail.com> - 2019-08-18 15:59 +0300
      Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-18 16:32 +0200
    Re: "C++: Size Matters in Platform Compatibility" Juha Nieminen <nospam@thanks.invalid> - 2019-08-19 07:29 +0000
      Re: "C++: Size Matters in Platform Compatibility" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-19 12:20 +0300
      Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-19 11:22 +0200
        Re: "C++: Size Matters in Platform Compatibility" Richard Damon <Richard@Damon-Family.org> - 2019-08-23 14:14 -0400
          Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-24 20:56 +0200
            Re: "C++: Size Matters in Platform Compatibility" Robert Wessel <robertwessel2@yahoo.com> - 2019-08-24 23:43 -0500
              Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-25 12:11 +0200
                Re: "C++: Size Matters in Platform Compatibility" Richard Damon <Richard@Damon-Family.org> - 2019-08-25 07:33 -0700
                Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-25 20:27 +0200
                Re: "C++: Size Matters in Platform Compatibility" Robert Wessel <robertwessel2@yahoo.com> - 2019-08-25 10:22 -0500
    Re: "C++: Size Matters in Platform Compatibility" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-19 15:05 -0500
      Re: "C++: Size Matters in Platform Compatibility" scott@slp53.sl.home (Scott Lurndal) - 2019-08-19 20:17 +0000
        Re: "C++: Size Matters in Platform Compatibility" David Brown <david.brown@hesbynett.no> - 2019-08-20 08:21 +0200
          Re: "C++: Size Matters in Platform Compatibility" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-20 14:38 -0500
      Re: "C++: Size Matters in Platform Compatibility" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-21 09:15 -0400
  Re: "C++: Size Matters in Platform Compatibility" Anton Shepelev <anton.txt@gmail.com> - 2019-08-18 15:20 +0300
    Re: "C++: Size Matters in Platform Compatibility" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-08-18 14:50 +0100

csiph-web