CVS difference for ai05s/ai05-0119-1.txt

--- ai05s/ai05-0119-1.txt	2010/06/14 01:24:49	1.4
+++ ai05s/ai05-0119-1.txt	2010/10/26 03:48:47	1.5
@@ -17,9 +17,9 @@
 Ada.Calendar time is not well-defined in the presence of daylight saving time
 adjustments.
 
-1. Ada.Calendar.Time_Of is ill-defined within the hour when the clock is adjusted
-backwards. The same year-month-day-seconds quadruple may denote two different dates.
-For example:
+1. Ada.Calendar.Time_Of is ill-defined within the hour when the clock is
+adjusted backwards. The same year-month-day-seconds quadruple may denote two
+different dates. For example:
 
 year => 2008,
 month => 10,
@@ -1010,5 +1010,757 @@
 Right. That's what I said during the call, that's what it says in the minutes
 that I have an action item to try to do, and that's what my research into
 Windows system calls after the call shows is the best plan.
+
+****************************************************************
+
+!topic Clarification of UTC_Time_Offset
+!reference 9.6.1(42)
+!from Adam Beneschan 10-06-29
+!discussion
+
+I don't know if this should be added to AI05-119, or if this a simple enough
+editorial comment to just go ahead and fix it now...
+
+9.6.1(42) says UTC_Time_Offset "Returns ... the difference between the
+implementation-defined time zone of Calendar, and UTC time".  To me, the English
+phrase "the difference between" is somewhat ambiguous as to the sign of the
+"difference".  May I suggest that a phrase like "This value is negative for time
+zones west of Greenwich, and positive for time zones east of Greenwich, when
+daylight savings time is not involved", or the reverse if that's what is really
+intended, be added? Or something to that effect?  Perhaps the sign is obvious to
+people who have worked a lot with Internet or Unix standards or the like, but I
+have a feeling someone will get tripped up by it.
+
+****************************************************************
+
+From: Dmitry A. Kazakov
+Date: Wednesday, June 30, 2010  9:34 PM
+
+It is unambiguous, provided "difference" means "-". The offset is exactly
+Local_Time - UTC.
+
+There is though a problem that the result does not tell if this difference is
+now "regular" or else of the daylight saving time.
+
+With the meaning "difference" is "-", UTC_Time_Offset depends on the current
+time.
+
+An alternative meaning could be the "regular", standard offset independent on
+the current time. E.g. GMT+02:00
+
+In both cases daylight saving time active flag is necessary to have
+UTC_Time_Offset useful. Even more important is a clear statement on whether
+Ada.Calendar.Time is a local political time (i.e. suffering large forward and
+backward jumps) or else an UTC + constant offset time.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, June 30, 2010  10:41 PM
+
+It's surely true in all existing versions of Ada that Ada.Calendar.Time is
+subject to jumps. That was decided early for Ada 83: see AI83-00195
+(http://archive.adaic.com/standards/83com/ai-00195-ra.wj). Note that this AI was
+considered a "Ramification". Nothing in Ada 95 or Ada 2005 changed that
+interpretation. It's not clear that anything *can* change that; if the operator
+manually changes the system time (including when a correction is applied
+automatically to resync the time with a time-base), most Ada implementations
+will immediately reflect that change. To avoid that, Ada implementations would
+have to maintain their own clock, which seems way out of bounds (and actively
+harmful on systems where the time is resynced to a supposedly more accurate
+time-base).
+
+The more interesting question is whether Ada 2012 will require that
+Ada.Calendar.Time include enough information to recover the UTC time from a
+value produced by Ada.Calendar.Clock. We believe that is enough to be able to
+reliably recover the UTC time (a variety of wording changes will be needed,
+which I am supposed to be working out in my copious spare time). It appears
+impossible to completely fix this problem for values produced from Time_Of,
+since there is never a way to know which of the two values is intended during
+the "ambiguous time". That is generally only one hour per year, so it probably
+not a serious problem.
+
+****************************************************************
+
+From: Adam Beneschan
+Date: Thursday, July 1, 2010  10:05 AM
+
+> It is unambiguous, provided "difference" means "-". The offset is
+> exactly Local_Time - UTC.
+
+(1) My main point is that I don't think "difference" (and in particular the
+phrase "difference between") means "-" in English.  I mean, it does, but not in
+a consistent way.  When I talk about the difference between A and B, I could
+mean A-B, B-A, or abs(A-B), and I don't think it's clear without context.
+(Suppose someone were to ask me, referring to my two sons, "What's the height
+difference between Mike and Steve", or "What's the height difference between
+Steve and Mike"?  I guarantee you I will give the same answer to both
+questions---"about 3 inches"; I will not answer "three inches" to one question
+and "negative three inches" to the other.)  I'm talking about normal English
+usage; if there were a standard mathematical usage, that usage would take
+precedence, but I don't think there is one and I don't believe mathematicians
+normally use this sort of phrasing.
+
+In any event, I don't think it's obvious, and can envision someone interpreting
+this wording to mean "the amount that must be added to time in the
+implementation-defined time zone of Calendar to get the UTC time", which would
+be a value of the opposite sign.
+
+(2) Another reason I don't think your point is quite sufficient: even if
+difference means "-", then the wording of 9.6.1(42) means (The
+implementation-defined time zone of Calendar) - (UTC time).  Unless there's some
+other definition I'm unaware of, a time zone is not a number, but is ... well I
+don't know, a geographical subset of the Earth's surface area?  This is a less
+important point, I suppose, because if the meaning of "difference between" were
+clear, I think it would be clear what is meant here even though the wording is
+slightly sloppy.
+
+Anyway, I realize that there are issues about daylight saving time (AI05-119),
+but this question of mine is independent of that issue.
+
+****************************************************************
+
+From: Adam Beneschan
+Date: Thursday, July 1, 2010  10:29 AM
+
+> It appears impossible to completely fix this problem for values
+> produced from Time_Of, since there is never a way to know which of the
+> two values is intended during the "ambiguous time". That is generally
+> only one hour per year, so it probably not a serious problem.
+
+I've been wondering whether Time_Of needs to be aware that the U.S. laws about
+when Daylight Savings Time starts and ends changed in 2007---or whether programs
+running in parts of Indiana need to be aware that there was no DST before 2007
+and there is now---or whether Time_Of on a computer running in Moscow needs to
+be aware that dates before 1918 are 13 days off?  OK, I'm joking about that last
+(I think it was resolved by AI95-351) but to what extent does Time_Of need to
+know about the history of DST regulation changes?  Or is this just covered by
+9.6(24)'s statement that "time zone" is implementation-defined, which means that
+implementations can do whatever they want (i.e. either take historical changes
+into account or ignore them as they choose)?  I'm guessing that the latter is
+the case---is that correct?
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, July 1, 2010  10:29 AM
+
+The practical answer is "whatever the host system does". There is no intent that
+Ada runtimes need to do their own time-zone manipulations, and thus whether or
+not Time_Of can do historical calculations depends solely on what the OS
+provides.
+
+(For Windows, Indiana was (is?) a separate time zone, so that sort of issue
+depends on whether or not the Indiana resident set their computer to use it. I
+hope the Ada standard isn't going to start telling people how to set their
+timezone settings!)
+
+Note that it doesn't matter if all that is done with the Time_Of value is to
+Split it later in the same (default) timezone: you'll have to get the same
+answers. The issue only comes up when you start using other timezones to extract
+values. It doesn't appear that anything portable can be mandated there.
+
+OTOH, values derived from Clock, we probably can mandate that that UTC can be
+reliably determined (since the timezone is known when the value is created, and
+there is no historical concerns). But Time_Of is always going to be a guess at
+best.
+
+****************************************************************
+
+From: Dmitry A.. Kazakov
+Date: Thursday, July 1, 2010  11:46 AM
+
+> It's surely true in all existing versions of Ada that
+> Ada.Calendar.Time is subject to jumps. That was decided early for Ada
+> 83: see AI83-00195
+> (http://archive.adaic.com/standards/83com/ai-00195-ra.wj). Note that
+> this AI was considered a "Ramification". Nothing in Ada 95 or Ada 2005
+> changed that interpretation. It's not clear that anything *can* change
+> that; if the operator manually changes the system time (including when
+> a correction is applied automatically to resync the time with a time-base), most Ada implementations will immediately reflect that change.
+
+I think that this is an independent issue. The source of clock whether it be
+machine's quartz or a user chaotically setting the system time is of no matter
+to Ada. It is given. There is no other source, we don't care how reliable it is.
+
+The actual problem is the semantics of how this source is treated within Ada. I
+see no other way than to treat it as UTC (or astronomical time, or similar).
+
+Political time requires too much overhead to implement. By this I mean precisely
+the following:
+
+   declare
+       T : Time := Clock;
+   begin
+      delay 60.0 * 10.0;
+      Put_Line (Boolean'Image (Clock > T));
+
+when executed at 31. Oct 2010, 2:59, a computer located in Central Europe shall
+print "FALSE."
+
+Is there any Ada compiler, which indeed implements this broken semantics?
+Does RM mandate this idiocy? Note, this unrelated to how Split and Time_Of are
+supposed to work. They can continue to use political time, no problem with that,
+if Ada.Calendar.Time meant to be UTC. If that were accepted, then the only
+addition needed would be a package with Split_Into_UTC and UTC_Of in it.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, July 1, 2010  5:52 PM
+
+> I think that this is an independent issue. The source of clock whether
+> it be machine's quartz or a user chaotically setting the system time
+> is of no matter to Ada. It is given.
+> There is no other source, we don't care how reliable it is.
+
+It's not at all an independent issue. You seem to be saying that the *reason*
+for a time jump is significant. But that makes no sense. Back in the days of
+MS-DOS, the way time zone changes were reflected was the same as in your wall
+clock: you changed the time twice a year. Saying that changing the time to
+reflect the time zone manually is somehow different than doing it automatically
+makes no sense.
+
+Similarly, whether the jumps occur "automatically" or "manually" is irrelevant.
+If your system is connected to a time base via NTP, it probably automatically
+adjusts the time periodically. How is this different (especially in terms of the
+Standard) than the automatic change that occurs when Daylight Savings Time
+changes? There is no practical difference.
+
+> The actual problem is the semantics of how this source is treated
+> within Ada. I see no other way than to treat it as UTC (or
+> astronomical time, or similar).
+
+That makes no sense as well. There is no requirement for an OS to even have a
+way to get UTC time or turn off automatic adjustments, and even if there is, Ada
+programs are likely to run on systems with those settings wrong.
+
+> Political time requires too much overhead to implement. By this I mean
+> precisely the following:
+>
+>    declare
+>        T : Time := Clock;
+>    begin
+>       delay 60.0 * 10.0;
+>       Put_Line (Boolean'Image (Clock > T));
+>
+> when executed at 31. Oct 2010, 2:59, a computer located in Central
+> Europe shall print "FALSE."
+
+No, this is clearly "implementation-defined". In fact, it ought to be
+"unspecified", in that it isn't even that practical to explain when the answer
+might be counter-intuitive. I have no idea when NTP is used to reset the time on
+my Windows systems, for instance, only that I set it up to do so. So I can't
+even "document" when the time might change, other than the useless advice that
+it will happen any time the system's clock is changed. (Duh!)
+
+If you want an monotonically-increasing time source, you need to use
+Ada.Real_Time. There can be no guarantees with Calendar.
+
+> Is there any Ada compiler, which indeed implements this broken
+> semantics?
+
+9.6(40.c) points out that Ada 83 pretty much required a direct mapping of Clock
+to the results of Split. I suspect that virtually all Ada 83 compilers had this
+"feature" (it's not a bug, as it is expected behavior). Compilers that haven't
+changed their implementations much from the Ada 83 ones (in order to keep upward
+compatibility) probably have the behavior. The IBM Rational compiler followed an
+Ada 83-style model back when we were discussing this the last time, and it
+probably still does.
+
+And I know Janus/Ada follows this model. Indeed, the heartbeat monitor that
+monitors our web server machine fails every November (as it waits 61 minutes
+instead of 1 minute). That's not worth fixing, given that the effect is to
+reboot the machine for no important reason once per year.
+
+> Does RM mandate this idiocy? Note, this unrelated to how Split and
+> Time_Of are supposed to work. They can continue to use political time,
+> no problem with that, if Ada.Calendar.Time meant to be UTC. If that
+> were accepted, then the only addition needed would be a package with
+> Split_Into_UTC and UTC_Of in it.
+
+This would be a royal pain on Windows. The basic Win32 time functions only
+provide a means to retrieve "local time" and "system time" (the latter is
+essentially UTC). There is no mechanism to convert one to the other. You can get
+the local time zone information and try to figure it out, but that is complex
+and error-prone.
+
+There are some newer APIs that would help, but they would mean that no Ada code
+could not run on older versions of Windows. Calendar is present in every Ada
+program, so anything it requires is required of all programs (unlike, say CPU
+affinities or CPU timing, which are only present if you use them). While it
+makes sense to only support Ada development tools on recent systems, it doesn't
+make sense to have such requirements on generated programs (there are a lot of
+perfectly useful old computers out there).
+
+Also, you are requiring a complete re-implementation of Ada.Calendar. That
+clearly will have other effects: files are no longer binary-compatible (the
+reason the year range was changed the way it was was so that could be maintained
+between Ada 95 and Ada 2005), indeed, Ada.Calendar.Time will be larger (it will
+have to include time zone information), which will break representation clauses.
+
+So, even if such a change is mandated, it would have to be only for Ada 2012;
+older versions will remain as they are.
+
+Personally, the only thing I care about is the ability to reliably get UTC time
+from Ada.Calendar.Clock. It doesn't make sense to complain about comparisons in
+this one case when there are many other cases that happen just as often that
+will not have an guaranteed result. (Without a guarantee for monotonically
+increasing time, like the one in Ada.Real_Time, you are always building on a
+house of sand.) Moreover, I don't recall any user that ever has complained about
+the comparisons of Ada.Calendar, and changing it would be a substantial expense.
+Use Ada.Real_Time if this is critical. Period.
+
+****************************************************************
+
+From: Dmitry A. Kazakov
+Date: Friday, July 2, 2010  3:28 AM
+
+> It's not at all an independent issue. You seem to be saying that the
+> *reason* for a time jump is significant. But that makes no sense. Back
+> in the days of MS-DOS, the way time zone changes were reflected was
+> the same as in your wall clock: you changed the time twice a year.
+> Saying that changing the time to reflect the time zone manually is
+> somehow different than doing it automatically makes no sense.
+
+Surely it does. The question is the model of clock Ada implementation represents. The mandated one seem to be:
+
+Ideal-UTC-clock + [noise' +] Political skew + noise -> Ada.Calendar.Time
+
+The proper one, must be
+
+Ideal-UTC-clock + noise -> Ada.Calendar.Time
+
+Your argument seems to be that because *some* noise is always added, then it is no matter whether it be just noise or Political skew + noise. That is wrong, because in reality the statistical behavior of the noise and Political skew are greatly different 
in all aspects.
+
+> Similarly, whether the jumps occur "automatically" or "manually" is
+> irrelevant. If your system is connected to a time base via NTP, it
+> probably automatically adjusts the time periodically. How is this
+> different (especially in terms of the Standard) than the automatic
+> change that occurs when Daylight Savings Time changes? There is no practical difference.
+
+The practical difference is that NTP adjustments are small and well distributed. Adding the Political skew upon them changes everything.
+
+>> The actual problem is the semantics of how this source is treated
+>> within Ada. I see no other way than to treat it as UTC (or
+>> astronomical time, or similar).
+>
+> That makes no sense as well.
+
+See the models above.
+
+...
+> No, this is clearly "implementation-defined". In fact, it ought to be
+> "unspecified", in that it isn't even that practical to explain when
+> the answer might be counter-intuitive. I have no idea when NTP is used
+> to reset the time on my Windows systems, for instance, only that I set
+> it up to do so. So I can't even "document" when the time might change,
+> other than the useless advice that it will happen any time the system's clock is changed.
+> (Duh!)
+
+No NTP client would do 10 minutes adjustments. It makes no sense to consider
+totally malfunctioning installation, like if you smashed the onboard quartz with
+the hammer.
+
+> If you want an monotonically-increasing time source, you need to use
+> Ada.Real_Time. There can be no guarantees with Calendar.
+
+That is impossible, because Ada.Real_Time.Time is not a real time in the sense,
+that it is not linked to a reliable external [real] time source. As such it is
+unusable for most networking/distributed/real-time applications.
+
+> And I know Janus/Ada follows this model. Indeed, the heartbeat monitor
+> that monitors our web server machine fails every November (as it waits
+> 61 minutes instead of 1 minute). That's not worth fixing, given that
+> the effect is to reboot the machine for no important reason once per year.
+
+I better leave that uncommented. (:-))
+
+>> Does RM mandate this idiocy? Note, this unrelated to how Split and
+>> Time_Of are supposed to work. They can continue to use political
+>> time, no problem with that, if Ada.Calendar.Time meant to be UTC. If
+>> that were accepted, then the only addition needed would be a package
+>> with Split_Into_UTC and UTC_Of in it.
+>
+> This would be a royal pain on Windows. The basic Win32 time functions
+> only provide a means to retrieve "local time" and "system time" (the
+> latter is essentially UTC). There is no mechanism to convert one to
+> the other. You can get the local time zone information and try to
+> figure it out, but that is complex and error-prone.
+
+I see no problem. GetSystemTime and GetSystemTimeAsFileTime do the job.
+
+The actual problem under Windows and many other OSes is an awful clock accuracy
+(even when GetSystemTimeAsFileTime is used, FILETIME was 100ns resolution). I
+suppose this is because Windows does not use the high-resolution CPU clock. So
+if you want to get a decent implementation of Clock under Windows, you have to
+use performance counters instead and periodically synchronize them with the
+readings of GetSystemTime in a background task. But all this has no connection
+to political vs physical time controversy.
+
+However, considering modern CPUs, I think it is time advise Ada compilers to use
+CPU clocks (ns resolution) as one of the time sources.
+
+> Also, you are requiring a complete re-implementation of Ada.Calendar.
+
+They must be, because the standard is broken. Once fixed, it will inevitably
+break some existing implementations.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, July 2, 2010  5:03 PM
+
+> Sent: Saturday, July 03, 2010 3:28 AM
+
+Speaking of time issues, your computer is sending messages a day ahead of time. We received this message at about 8:30 UTC on Friday. If we were running Spam Assassin here, we would never have seen it (SA treats messages dated in the future as almost cert
ain spam). I hope you're not using an Ada program for sending mail...
+
+> Your argument seems to be that because *some* noise is always added,
+> then it is no matter whether it be just noise or Political skew +
+> noise. That is wrong, because in reality the statistical behavior of
+> the noise and Political skew are greatly different in all aspects.
+
+But you are claiming that there is some difference between "Political skew"
+as added by a computer operating system and that added by the end user. I don't
+see this difference. I have known a number of people who reset the times on
+their Windows machines by hand twice a year. (I even have to do that on some of
+the dual-boot systems here.) On such systems, any information about "political
+skew" is going to be completely wrong. (Similarly, a heck of a lot of Windows 98
+and Windows 2000 computers have the old time zone information for the US and
+change the time on the wrong days. People using such old computers will manually
+correct the time 4 times a year.)
+
+And I also don't see any difference between the automatic changes made by time
+zone information and the automatic changes made by NTP clock resets (or for that
+matter, because of clock drift, see below).
+
+> > Similarly, whether the jumps occur "automatically" or "manually" is
+> > irrelevant. If your system is connected to a time base via NTP, it
+> > probably automatically adjusts the time periodically. How is this
+> > different (especially in terms of the Standard) than the automatic
+> > change that occurs when Daylight Savings Time changes?
+> There is no practical difference.
+>
+> The practical difference is that NTP adjustments are small and well
+> distributed. Adding the Political skew upon them changes everything.
+
+This is clearly not true, at least on Windows systems, because of the use of the
+high-performance counter. See below.
+
+> >> The actual problem is the semantics of how this source is treated
+> >> within Ada. I see no other way than to treat it as UTC (or
+> >> astronomical time, or similar).
+> >
+> > That makes no sense as well.
+>
+> See the models above.
+
+It still doesn't make any sense, especially from a Standards perspective.
+You want the language to ban using one particular reason for time jumps while
+allowing all others, even though the others cause more damage to running
+programs (as they aren't predictable in time nor size). That is impossible to
+do, especially when there is no way to separate such changes from any other
+(given that manual changes may be used to effect daylight savings changes).
+
+...
+> No NTP client would do 10 minutes adjustments. It makes no sense to
+> consider totally malfunctioning installation, like if you smashed the
+> onboard quartz with the hammer.
+
+Actually, the implementation that you want for Windows essentially requires that
+(see below).
+
+> > If you want an monotonically-increasing time source, you need to use
+> > Ada.Real_Time. There can be no guarantees with Calendar.
+>
+> That is impossible, because Ada.Real_Time.Time is not a real time in
+> the sense, that it is not linked to a reliable external [real] time
+> source. As such it is unusable for most
+> networking/distributed/real-time applications.
+
+If you need true external time, you need to get it from a true external source.
+No computer time is accurate enough for that, and certainly Ada.Calendar.Time is
+not intended for that purpose.
+
+When I was a student, I learned that time is *never* the same on two different
+computers, and it should *never* be used in a communication algorithm. If it is
+used at all, it should be in an advisory/debugging function. And indeed, that is
+how it is used in protocols like SMTP and HTTP -- the time is passed, but it
+doesn't really matter. (Case in point, the message I'm replying to whose clock
+is a day off. If the time was really significant, it couldn't have been
+delivered.) Ada.Calendar is good enough for that.
+
+Perhaps there are situations that do really need careful time information, but
+those are clearly not those that computer clocks and Ada.Calendar are intended
+for. I'd suggest using an NTP library for that purpose.
+
+> > And I know Janus/Ada follows this model. Indeed, the heartbeat
+> > monitor that monitors our web server machine fails every November
+> > (as it waits
+> > 61 minutes instead of 1 minute). That's not worth fixing, given that
+> > the effect is to reboot the machine for no important reason once per year.
+>
+> I better leave that uncommented. (:-))
+
+Two weeks work to fix one glitch per year makes no sense. It's the same reason
+that I stopped doing updates to my spam filter -- the 5-10 extra messages that
+would be blocked take only a couple of minutes per day to process and discard --
+spending two weeks or more of work time to save 2 minutes per day would be
+senseless.
+
+...
+> > This would be a royal pain on Windows. The basic Win32 time
+> > functions only provide a means to retrieve "local time" and "system
+> > time" (the latter is essentially UTC). There is no mechanism to
+> > convert one to the other. You can get the local time zone
+> > information and try to figure it out, but that is complex and error-prone.
+>
+> I see no problem. GetSystemTime and GetSystemTimeAsFileTime do the
+> job.
+
+My point is that there is no sane way to get the local time from the SystemTime.
+Your claim that Split without a time zone parameter should still work as it does
+currently implies that is possible and necessary (since it has to return the
+local time, not the system time).
+
+...
+> However, considering modern CPUs, I think it is time advise Ada
+> compilers to use CPU clocks (ns resolution) as one of the time
+> sources.
+
+I don't think this can be done in the Standard, as this is a quality of
+implementation problem. Moreover, I doubt that most readers of Implementation
+Advice would have a clue what "CPU clocks" means. We can't mention specific
+operating systems in IA. Moreover, I don't think there is any Linux/Unix
+counterpart to the performance counter of Windows, so I don't think there is a
+way to even do this on those systems.
+
+In any case, all of the Windows implementations that we tested for Claw used the
+performance counter except for the Rational compiler (and the Windows version of
+the Rational compiler no longer exists anyway - even if you had a copy, the
+license keys wouldn't work and it wouldn't run).
+
+Note that using the performance counter has the effect of causing large jumps at
+random intervals. The way the Janus/Ada implementation works is that we "base"
+the performance counter with the local time at start up. When clock is called,
+we use the base plus the performance counter in order to produce the result
+time. However, if that result differs more than 5 minutes from the  local time
+as returned from the OS, we then "rebase" the clock and return the local time
+instead. We do this so that clock drift, NTP adjustments, manual adjustments,
+and daylight saving time changes are all reflected in the result time. This is
+important for long running programs - Ada.Calendar needs to reflect the correct
+(as seen by the computer) time. The net effect of this means that there will be
+random jumps of at least 5 minutes periodically for a long running program. (We
+do have a minimum time between checks for rebasing, in order to improve the
+performance of Ada.Calendar.Clock. So programs that only run a few minutes -
+like ACATS tests - will never see a rebasing.)
+
+Obviously, the 5 minute number is arbitrary. It could be more or less, but you
+have to have such a number. If you rebased always, of course the effect would be
+to ignore the performance counter completely. If you never rebased, long-running
+programs like our web server (which is intended to run months at a time) would
+never get the effect of NTP clock settings and also could get far away from the
+actual time.
+
+Our experiments on Windows 98 and Windows 2000 systems back when this was
+implemented showed that clock drift was a serious problem; we saw machines where
+rebasing happened ever few hours as the local time and the performance counters
+drifted apart rapidly. Not sure if more modern machines are any better in this
+respect, but I would guess not (and NTP clock resets could make the problem even
+more severe).
+
+The rules you are suggesting would make it impossible to use the performance
+counter, as programs that run more than a few hours have to be able to rebase
+the clock. But that rebasing would by definition violate the model that you set
+out. Wording to require the model that you want would almost certainly make
+rebasing wrong as well -- which would be very bad.
+
+> > Also, you are requiring a complete re-implementation of Ada.Calendar.
+>
+> They must be, because the standard is broken. Once fixed, it will
+> inevitably break some existing implementations.
+
+OK, but then it is necessary to consider the impact on customers. For instance,
+if rebasing of times is banned, then long-running applications cannot depend on
+Ada.Calendar to retrieve local or UTC time. (The time could drift too far away
+to be meaningful - I have a temperature gauge that includes a clock that I never
+change - it has drifted 40 minutes away from the correct time in just over a
+year of operation. Most computer clocks are about that accurate in the long haul
+-- that's why we have NTP.)
+
+In any case, this discussion with you has been very enlightening. I was in fact
+in favor of some sort of fix to allow retrieving of UTC time reliably. But this
+discussion has convinced me that that is a fool's game - it is impossible to
+make a meaningful requirement that also does not prevent important
+implementation strategies. As such, I don't plan to waste time attempting to
+write language to mandate anything, and will recommend No Action on AI05-0119-1.
+
+****************************************************************
+
+From: Dmitry A. Kazakov
+Date: Saturday, July 3, 2010  4L57 AM
+
+> Speaking of time issues, your computer is sending messages a day ahead
+> of time. We received this message at about 8:30 UTC on Friday.
+
+It happens sporadically, I don't know why and when.
+
+> ...
+>>> It's not at all an independent issue. You seem to be saying that the
+>>> *reason* for a time jump is significant. But that makes no sense.
+>>> Back in the days of MS-DOS, the way time zone changes were reflected
+>>> was the same as in your wall clock: you changed the time twice a year.
+>>> Saying that changing the time to reflect the time zone manually is
+>>> somehow different than doing it automatically makes no sense.
+>>
+>> Surely it does. The question is the model of clock Ada implementation
+>> represents. The mandated one seem to be:
+>>
+>> Ideal-UTC-clock + [noise' +] Political skew + noise ->
+>> Ada.Calendar.Time
+>>
+>> The proper one, must be
+>>
+>> Ideal-UTC-clock + noise -> Ada.Calendar.Time
+>>
+>> Your argument seems to be that because *some* noise is always added,
+>> then it is no matter whether it be just noise or Political skew +
+>> noise. That is wrong, because in reality the statistical behavior of
+>> the noise and Political skew are greatly different in all aspects.
+>
+> But you are claiming that there is some difference between "Political skew"
+> as added by a computer operating system and that added by the end user.
+
+Certainly yes. The end user is responsible for setting the clock. Whatever he
+does this is *the* UTC source the program must deal with. Political skew per
+definition and intent is a *different* time.
+
+> And I also don't see any difference between the automatic changes made
+> by time zone information and the automatic changes made by NTP clock
+> resets (or for that matter, because of clock drift, see below).
+
+As above, these are different times, apples and oranges.
+
+...
+>>> That makes no sense as well.
+>>
+>> See the models above.
+>
+> It still doesn't make any sense, especially from a Standards perspective.
+> You want the language to ban using one particular reason for time
+> jumps while allowing all others, even though the others cause more
+> damage to running programs (as they aren't predictable in time nor size).
+
+Not at all. What I want is time to be defined in terms of UTC. If you want to
+keep it political you must either throw away time arithmetic because it is
+inconsistent. Note that any alternative, like to add some fields to Time object
+in order to fix arithmetic, would mean making it UTC.
+
+...
+> If you need true external time, you need to get it from a true
+> external source. No computer time is accurate enough for that, and
+> certainly Ada.Calendar.Time is not intended for that purpose.
+>
+> When I was a student, I learned that time is *never* the same on two
+> different computers, and it should *never* be used in a communication
+> algorithm. If it is used at all, it should be in an advisory/debugging
+> function. And indeed, that is how it is used in protocols like SMTP
+> and HTTP
+> -- the time is passed, but it doesn't really matter. (Case in point,
+> the message I'm replying to whose clock is a day off.
+
+If time is different, how do you know that it was day off? (:-))
+
+Though any two asynchronous agents have different time, at the same time (no pun
+intended), any two communicating agents cannot have arbitrary times.
+
+> Perhaps there are situations that do really need careful time
+> information, but those are clearly not those that computer clocks and
+> Ada.Calendar are intended for. I'd suggest using an NTP library for that
+> purpose.
+
+I see no reason why Ada.Calendar should not use the best available time source.
+
+>>> And I know Janus/Ada follows this model. Indeed, the heartbeat
+>>> monitor that monitors our web server machine fails every November
+>>> (as it waits
+>>> 61 minutes instead of 1 minute). That's not worth fixing, given that
+>>> the effect is to reboot the machine for no important reason once per year.
+>>
+>> I better leave that uncommented. (:-))
+>
+> Two weeks work to fix one glitch per year makes no sense.
+
+It makes a lot of sense for industrial system, for which Ada must be the
+language of choice. I cannot remember any system we installed, which didn't use
+UTC stamps. Political time is no starter.
+
+...
+>> I see no problem. GetSystemTime and GetSystemTimeAsFileTime do the
+>> job.
+>
+> My point is that there is no sane way to get the local time from the
+> SystemTime.
+
+Why should you care? Your point seem to be that Clock may deliver any rubbish.
+
+> Your claim that Split without a time zone parameter should still work
+> as it does currently implies that is possible and necessary (since it
+> has to return the local time, not the system time).
+
+I see no problem with that. As you said earlier, Ada RTL would use system
+services, the way how they work or do not work is not our business. As for
+Windows, Split from UTC can be implemented as FileTimeToLocalFileTime +
+FileTimeToSystemTime.
+
+> Note that using the performance counter has the effect of causing
+> large jumps at random intervals. The way the Janus/Ada implementation
+> works is that we "base" the performance counter with the local time at
+> start up. When clock is called, we use the base plus the performance
+> counter in order to produce the result time. However, if that result
+> differs more than 5 minutes from the  local time as returned from the
+> OS, we then "rebase" the clock and return the local time instead. We
+> do this so that clock drift, NTP adjustments, manual adjustments, and
+> daylight saving time changes are all reflected in the result time.
+> This is important for long running programs - Ada.Calendar needs to reflect the correct (as seen by the computer) time.
+> The net effect of this means that there will be random jumps of at
+> least 5 minutes periodically for a long running program. (We do have a
+> minimum time between checks for rebasing, in order to improve the
+> performance of Ada.Calendar.Clock. So programs that only run a few
+> minutes - like ACATS tests - will never see a rebasing.)
+
+We do it differently. Basically it is a digital filter with takes performance
+counter readings and the system time (UTC). The filter is run each second or so.
+It has a window of at least 100 weighted readings. The output of the filter is
+the base to add to the performance counter in order to get FILETIME. So far we
+didn't experienced jumps.
+
+> Obviously, the 5 minute number is arbitrary. It could be more or less,
+> but you have to have such a number. If you rebased always, of course
+> the effect would be to ignore the performance counter completely. If
+> you never rebased, long-running programs like our web server (which is
+> intended to run months at a time) would never get the effect of NTP
+> clock settings and also could get far away from the actual time.
+
+Right, this is because the quartz has poor quality. We measured its drift using
+the above technique, it was about 5 microseconds per second between two
+identical machines.
+
+Note that even if the CPU and BIOS quartz were perfect, you could not use your
+technique, because during reading performance counter and system time the Ada
+task might get preempted. In our filter we read performance counter twice and
+use the difference as the weight to the reading (which itself is a mean of two).
+It is a bit complicated, but doable.
+
+>>> Also, you are requiring a complete re-implementation of Ada.Calendar.
+>>
+>> They must be, because the standard is broken. Once fixed, it will
+>> inevitably break some existing implementations.
+>
+> OK, but then it is necessary to consider the impact on customers. For
+> instance, if rebasing of times is banned,
+
+Not at all. I would mandate periodical rebasing if the implementation uses more
+than one time source, e.g. CPU and BIOS clocks.
 
 ****************************************************************