CVS difference for ai05s/ai05-0119-1.txt
--- ai05s/ai05-0119-1.txt 2009/02/18 05:49:30 1.3
+++ ai05s/ai05-0119-1.txt 2010/06/14 01:24:49 1.4
@@ -59,7 +59,7 @@
!wording
** TBD **
-
+
!discussion
[Editor's note: To think about this in the US, use the time November 02, 2008
@@ -104,8 +104,8 @@
!example
+
-
!ACATS test
@@ -154,10 +154,10 @@
Date: Wednesday, August 6, 2008 2:16 PM
> 1. What is the result (according to the language reference manual) of:
->
-> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10,
+>
+> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10,
> 2.5*60.0*60.0));
->
+>
> called on a machine with the time zone Amsterdam, Berlin, Bern...
This depends on the definition of the user-defined procedure UTC_Time_Offset.
@@ -216,9 +216,9 @@
I think that 42/2 is fine because UTC_Time_Offset *is* a function.
But 44/2 could be worded better because Difference is *not* a function.
Perhaps "Computes the difference between...".
-
+
> RM 9.6 24/2:
->
+>
> "The functions Year, Month, Day, and Seconds return the corresponding
> values for a given value of the type Time, as appropriate to an
> implementation-defined time zone; the procedure Split returns all four
@@ -236,8 +236,8 @@
From: Dmitry A. Kazakov
Date: Thursday, August 7, 2008 3:30 PM
-> I think that 42/2 is fine because UTC_Time_Offset *is* a function.
-> But 44/2 could be worded better because Difference is *not* a
+> I think that 42/2 is fine because UTC_Time_Offset *is* a function.
+> But 44/2 could be worded better because Difference is *not* a
> function. Perhaps "Computes the difference between...".
That does not compute either. Because "the difference" implies that
@@ -246,7 +246,7 @@
...
-> I think you are reading too much in the word "conversely". I don't
+> I think you are reading too much in the word "conversely". I don't
> believe that it was intended to imply reversibility.
If that is true, then the text becomes meaningless: "four corresponding
@@ -273,12 +273,12 @@
From: Adam Beneschan
Date: Thursday, August 7, 2008 7:01 PM
-> > I think that 42/2 is fine because UTC_Time_Offset *is* a function.
-> > But 44/2 could be worded better because Difference is *not* a
+> > I think that 42/2 is fine because UTC_Time_Offset *is* a function.
+> > But 44/2 could be worded better because Difference is *not* a
> > function. Perhaps "Computes the difference between...".
->
-> That does not compute either. Because "the difference" implies that
-> there is exactly one result for each argument, which is equivalent of
+>
+> That does not compute either. Because "the difference" implies that
+> there is exactly one result for each argument, which is equivalent of
> being a mathematical function.
But there *is* one "difference". The part that returns "the difference"
@@ -292,10 +292,10 @@
Ada function.
...
-> > I think you are reading too much in the word "conversely". I don't
+> > I think you are reading too much in the word "conversely". I don't
> > believe that it was intended to imply reversibility.
->
-> If that is true, then the text becomes meaningless: "four
+>
+> If that is true, then the text becomes meaningless: "four
> corresponding values" of what? How they correspond etc.
It means that Split returns four OUT parameters, "Year", "Month", "Day",
@@ -303,11 +303,11 @@
the functions of the same names would return. Thus, Split (Date, Y, M, D, S)
sets Y := Year(Date), M := Month(Date), and so on.
That's what "corresponding" means. It has nothing whatsoever to do with the
-second sentence of paragraph 24, nor of the Time_Of function.
+second sentence of paragraph 24, nor of the Time_Of function.
Your issues regarding how this package works around Daylight Savings Time
changes point out a real problem. But the questions about wording that you're
-asking above don't have anything to do with this issue.
+asking above don't have anything to do with this issue.
****************************************************************
@@ -315,10 +315,10 @@
Date: Friday, August 8, 2008 3:09 AM
...
->> That does not compute either. Because "the difference" implies that
->> there is exactly one result for each argument, which is equivalent of
+>> That does not compute either. Because "the difference" implies that
+>> there is exactly one result for each argument, which is equivalent of
>> being a mathematical function.
->
+>
> But there *is* one "difference".
No, I meant UTC_Time_Offset, which depends on the definition of the
@@ -334,11 +334,11 @@
I thought it wished to preserve political time...]
...
-> It means that Split returns four OUT parameters, "Year", "Month",
-> "Day", and "Seconds"; and these OUT parameters are set to the same
-> values that the functions of the same names would return. Thus, Split
+> It means that Split returns four OUT parameters, "Year", "Month",
+> "Day", and "Seconds"; and these OUT parameters are set to the same
+> values that the functions of the same names would return. Thus, Split
> (Date, Y, M, D, S) sets Y := Year(Date), M := Month(Date), and so on.
-> That's what "corresponding" means. It has nothing whatsoever to do
+> That's what "corresponding" means. It has nothing whatsoever to do
> with the second sentence of paragraph 24, nor of the Time_Of function.
How so? The wording is:
@@ -354,9 +354,9 @@
inconsistent with "the difference" allegedly returned by UTC_Time_Offset,
etc.
-> Your issues regarding how this package works around Daylight Savings
-> Time changes point out a real problem. But the questions about
-> wording that you're asking above don't have anything to do with this
+> Your issues regarding how this package works around Daylight Savings
+> Time changes point out a real problem. But the questions about
+> wording that you're asking above don't have anything to do with this
> issue.
My question was about the semantics. Actually, I don't care much about
@@ -372,13 +372,13 @@
Date: Friday, August 8, 2008 2:24 PM
> How so? The wording is:
->
-> "The functions Year, Month, Day, and Seconds return the
-> corresponding values for a given value of the type Time ..." -- 9.6
+>
+> "The functions Year, Month, Day, and Seconds return the
+> corresponding values for a given value of the type Time ..." -- 9.6
> 24/2
->
-> I.e. the "correspondence" is to be between Year, Month, Day, Seconds
-> and Time. Now, do the quadruple (y, m, d, s) unambiguously denote a
+>
+> I.e. the "correspondence" is to be between Year, Month, Day, Seconds
+> and Time. Now, do the quadruple (y, m, d, s) unambiguously denote a
> political time date or not?
OK, I see. The word "corresponding" appears twice in this paragraph,
@@ -575,7 +575,7 @@
Ada.Calendar.Time_Zones.To_UTC (T, 2*60);
2. Conversion from UTC. Assuming the declarations above:
-
+
Ada.Calendar.Time_Zones.To_Calendar_Time (T_CEST) = T
Ada.Calendar.Time_Zones.To_Calendar_Time (T_CET) = T
@@ -631,7 +631,7 @@
then it would be good to present an implementation model for your
proposal, since it seems to require that the time values "remember"
how they were obtained. (And that seems fairly horrendous.)
-
+
> In particular, if a difference is calculated between two times of which one
> belongs to the overlapping hour, then this time is treated as having the
> same UTC offset as another. For example:
@@ -641,7 +641,7 @@
It seems to me that you are just trying to infer a timezone that was never
provided to Time_Of in the first place. You might guess right some of the
time, but that's not better than the current state of affairs.
-
+
The only sound way to address the issues you are mentioning would be to
have variants of Time_Of et al. that take the designation of a timezone
(not only a time offset) and keep track of all the time changes that take
@@ -656,8 +656,8 @@
Date: Friday, August 29, 2008 4:16 AM
...
-> Taken at face value, this statement doesn't make any sense. If T1 =
-> T2 then presumably T1 + 3600.0 = T2 + 3600.0, but since T1 + 3600.0 is
+> Taken at face value, this statement doesn't make any sense. If T1 =
+> T2 then presumably T1 + 3600.0 = T2 + 3600.0, but since T1 + 3600.0 is
> T2,
No, T1 + 3600.0 /= T2.
@@ -673,9 +673,9 @@
T1 + 3600.0 = T2 + 3600.0
-> I don't think that you imply this, but then it would be good to
-> present an implementation model for your proposal, since it seems to
-> require that the time values "remember" how they were obtained. (And
+> I don't think that you imply this, but then it would be good to
+> present an implementation model for your proposal, since it seems to
+> require that the time values "remember" how they were obtained. (And
> that seems fairly horrendous.)
The semantics of Time + Duration is well-defined:
@@ -692,18 +692,18 @@
3. Result is converted back to the political time. This operation is always
unambiguous.
->> In particular, if a difference is calculated between two times of
->> which one belongs to the overlapping hour, then this time is treated
+>> In particular, if a difference is calculated between two times of
+>> which one belongs to the overlapping hour, then this time is treated
>> as having the same UTC offset as another. For example:
->
+>
> This doesn't help if both times belong to the overlapping hour.
In this case the difference is calculated directly considering the UTC
offsets equal.
> And it is
-> not clear that this is what you want in the other cases anyway. It
-> seems to me that you are just trying to infer a timezone that was
+> not clear that this is what you want in the other cases anyway. It
+> seems to me that you are just trying to infer a timezone that was
> never provided to Time_Of in the first place.
It is true that arithmetic of political time cannot be consistently defined
@@ -713,18 +713,18 @@
that it should not. Yet, an implementation is free to choose UTC, internally
and then mangle +, -, =, in accordance to the "political will" (:-))...
-> The only sound way to address the issues you are mentioning would be
-> to have variants of Time_Of et al. that take the designation of a
-> timezone (not only a time offset) and keep track of all the time
+> The only sound way to address the issues you are mentioning would be
+> to have variants of Time_Of et al. that take the designation of a
+> timezone (not only a time offset) and keep track of all the time
> changes that take place in that timezone.
That would not define the semantics of Time. My proposal does it, by defining
the political time in terms of UTC. This is how the political time is defined
in the real world.
-> That was rejected long ago, because it seems absurd to have the Ada
-> runtime know about all this timezone stuff, which changes periodically
-> anyway. This is especially true in an embedded environment, where
+> That was rejected long ago, because it seems absurd to have the Ada
+> runtime know about all this timezone stuff, which changes periodically
+> anyway. This is especially true in an embedded environment, where
> no-one cares about timezones.
Right, my proposal provides a way to define Time on the platform where UTC
@@ -765,7 +765,7 @@
procedures with Time_Zone parameters treat the Date as having the system clock's
offset, and return the components of the Date converted to the specified offset.
-(Calling the parameter Time_Zone seems a bit misleading, since "time zone"
+(Calling the parameter Time_Zone seems a bit misleading, since "time zone"
usually refers to a political concept, and the parameter is really an arbitrary
offset unrelated to any such concept.)
@@ -774,5 +774,241 @@
as strings (since this is a malleable definition and cannot be represented by
arbitrary numeric values or an enumeration type), such as "US/Mountain" and
"Europe/Dublin". Clearly such operations do not belong in the existing packages.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, May 20, 2010 6:06 PM
+
+On our phone call today, we had a somewhat mind-bending discussion of calendar, time zones, and daylight-savings/summer time.
+
+We recognized that there are two
+distinct strategies for representing
+Calendar.Time, one where the time is kept in UTC internally, and Calendar.Split and Calendar.Time_Of worry about the "local"
+time zone. The other is that Time is represented in local time, and Calendar.Time_Of and Calendar.Split are trivial.
+
+Here are some interesting questions:
+
+What does "-"(Time, Time) return for times that cross a daylight/summer timezone change? Clearly if Time is represented internally as UTC time, this is very straightforward.
+
+If Time is represented as a local time that reflects daylight-savings/summer time, but with no internal bit indicating whether daylight/summer time was in effect when the local time was stored, then it seems clear that "-" will necessarily return a value
of Duration that corresponds to 3600.0 seconds more or 3600.0 seconds less than the actual number of seconds that pass between the two times.
+This seems highly undesirable.
+
+This leads me to suggest that for an implementation that stores local time, during a single execution of an Ada program, all times should use the same time zone, even if daylight/summer time begins or ends during the execution. This also means that UTC_T
ime_Offset should return the same value independent of the Date parameter, reflecting the time zone at the moment when program execution began. This means that Clock will have to undo the effects of any change in daylight savings/summer time since the pro
gram execution began, if the underlying O/S reflects the change immediately. Similarly Split and Time_Of will presume the program-start timezone, even if they represent times when the timezone would be different due to daylight/summer time.
+
+Alternatively, if Calendar.Time is represented as UTC time, then it would be feasible for UTC_Time_Offset to give different values depending on the Date parameter, and for Calendar.Time_Of and Calendar.Split to reflect the different UTC_Time_Offset based
on the Time value represented by the parameters. However, Time_Of would be ambiguous for 2AM-3AM on the day daylight/summer time ends, and the implementation would need to pick one or the other. To be consistent with the implementations using local time,
we would want to specify that when ambiguous, a UTC_Time_Offset is used by Time_Of that corresponds to its value when program execution began.
+
+Of course even more consistent would be to have both implementation approaches always presume the time zone when program execution begins, and have UTC_Time_Offset always return the same value, independent of the Date parameter. However, that seems to fl
y in the face of the description of UTC_Time_Offset.
+
+The other solution is to effectively require implementations to use UTC time internally, or at least an indication of whether a given "local" time is or is not a daylight/summer time, so that "-", "<", Difference, etc., can properly reflect the true diffe
rence in time. This would then allow UTC_Time_Offset to depend on the Date parameter, as implied by it RM definition.
+
+Uggh...
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, May 20, 2010 6:39 PM
+
+...
+> If Time is represented as a local time that reflects
+> daylight-savings/summer time, but with no internal bit indicating
+> whether daylight/summer time was in effect when the local time was
+> stored, then it seems clear that "-" will necessarily return a value
+> of Duration that corresponds to 3600.0 seconds more or 3600.0 seconds
+> less than the actual number of seconds that pass between the two
+> times.
+> This seems highly undesirable.
+
+Nevertheless, it's been the case in at least some Ada implementations for
+decades. (It causes interesting effects in long-running programs that happen to
+running when the time zone changes. For example, the heartbeat monitor on our
+webserver fails each March because it waits 61 minutes (instead of 1 minute) to
+send the heartbeat signal to the hardware -- so the hardware monitor assumes the
+computer failed and does a reboot. Didn't see worth fixing.)
+
+We could try to adopt rules to change that, but they would be inconsistent with
+actual practice on Windows.
+
+> This leads me to suggest that for an implementation that stores local
+> time, during a single execution of an Ada program, all times should
+> use the same time zone, even if daylight/summer time begins or ends
+> during the execution.
+> This also means that UTC_Time_Offset should return the same value
+> independent of the Date parameter, reflecting the time zone at the
+> moment when program execution began. This means that Clock will have
+> to undo the effects of any change in daylight savings/summer time
+> since the program execution began, if the underlying O/S reflects the
+> change immediately.
+> Similarly Split and Time_Of will presume the program-start timezone,
+> even if they represent times when the timezone would be different due
+> to daylight/summer time.
+
+That sounds fine, except that it isn't implementable on Windows. Windows has two
+time functions: GetSystemTime (which is UTC time) and GetLocalTime (which gets
+the current local time). To do this, you would have to use the System (UTC) time
+and do conversions after the fact -- at which point you might was well abandon
+the entire local time model.
+
+It also should be noted that the time zone model isn't even supported on Windows
+95/98/ME, which is one reason that we never considered using it. (While you can
+retrieve the current time zone on Windows 95/98/ME, the conversion from
+SystemTime (UTC) to a specific local time is missing.) This isn't a big deal
+anymore, although I would still continue to support at least Windows 98 (because
+my home computer is still Windows 98 and there is no reason to update a computer
+that doesn't connect to the Internet, especially as that would require replacing
+my bookkeeping and database software - and I still want to use Ada at home).
+
+> Alternatively, if Calendar.Time is represented as UTC time, then it
+> would be feasible for UTC_Time_Offset to give different values
+> depending on the Date parameter, and for Calendar.Time_Of and
+> Calendar.Split to reflect the different UTC_Time_Offset based on the
+> Time value represented by the parameters. However, Time_Of would be
+> ambiguous for 2AM-3AM on the day daylight/summer time ends, and the
+> implementation would need to pick one or the other. To be consistent
+> with the implementations using local time, we would want to specify
+> that when ambiguous, a UTC_Time_Offset is used by Time_Of that
+> corresponds to its value when program execution began.
+
+Sounds painful, as you would have to remember whether or not daylight savings
+was active when the program started. For something that happens once per year,
+I'd probably suggest just requiring one or the other results.
+
+> Of course even more consistent would be to have both implementation
+> approaches always presume the time zone when program execution begins,
+> and have UTC_Time_Offset always return the same value, independent of
+> the Date parameter.
+> However, that seems to fly in the face of the description of
+> UTC_Time_Offset.
+
+It also would be inconsistent with current practice on Windows (at least). You
+have to work hard on Windows to avoid reflecting the daylight saving change
+immediately, and I don't think anyone does that. (Use Ada.Real_Time for delays!)
+
+> The other solution is to effectively require implementations to use
+> UTC time internally, or at least an indication of whether a given
+> "local" time is or is not a daylight/summer time, so that "-", "<",
+> Difference, etc., can properly reflect the true difference in time.
+> This would then allow UTC_Time_Offset to depend on the Date parameter,
+> as implied by it RM definition.
+
+I think this is what is required, as your other schemes end up working this way
+on Windows anyway. So why bother defining them? But note that this is definitely
+inconsistent with current practice on Windows. The change is not a big deal
+(probably would fix more bugs than it causes), but clearly more than a pure BI
+(that is, this is something that I would prefer to be clearly different between
+Ada 2005 and Ada 2012 so that implementations can determine where to put the
+pain for their customers).
+
+> Uggh...
+
+Well, now you have a better appreciation of why I've been frustrated talking to
+you (and others) on this topic.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Thursday, May 20, 2010 8:32 PM
+
+So it sounds like you agree we should
+require "Calendar.Time" to preserve enough information so that UTC_Time_Offset
+can be computed properly, by, for example, having a bit indicating whether or
+not the value corresponds to daylight/summer time.
+
+Or by using UTC time internally.
+
+****************************************************************
+
+From: Bob Duff
+Date: Thursday, May 20, 2010 8:36 PM
+
+> On our phone call today, we had a somewhat mind-bending discussion of
+> calendar, time zones, and daylight-savings/summer time.
+
+Mind-bending indeed. The concept of "time" seems simple on the surface, but it
+is surprisingly complicated! I don't get it.
+
+> We recognized that there are two
+> distinct strategies for representing
+> Calendar.Time, one where the time is kept in UTC internally, and
+> Calendar.Split and Calendar.Time_Of worry about the "local"
+> time zone. The other is that Time is represented in local time, and
+> Calendar.Time_Of and Calendar.Split are trivial.
+
+I think you're mixing up two things:
+
+ - An implementation might represent Time in UTC, or in local time.
+
+ - An implementation might represent Time as an integer number of
+ zilliseconds(*) since some epoch, or as a record containing
+ something like (year, month, day, hour, minute, second).
+
+But anyway, I think this is all a tempest in a teapot. Hard real-time systems
+that really care about time don't go around changing the system clock to match
+whatever some politicians say is the local political time. And those are the
+kind of systems that really care that X - Y gives exactly 3600.0 for that
+strange hour during the daylight "savings" transition.
+
+Think about a GPS system, which cares about speed-of-light transmissions from
+some satellites to some earth-bound devices. Those folks aren't going to mess
+around with political time -- they're going to use some stable standard, like
+UTC. I'll bet that satellite doesn't have any TIMEZONE or DAYLIGHT_SAVINGS
+environment variables on it, being modified willy-nilly by the sysadmins or the
+operating system!
+
+(*) zillisecond = zillionth of a second. Could be a nanosecond or a picosecond,
+or whatever. Some small fraction of a second. And "integer number of
+zilliseconds" is the same as a fixed-point number of seconds, with 'Small = 1
+zillisecond. E.g. Duration.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, May 20, 2010 9:00 PM
+
+Well, GPS uses its own time which is subtly wrong (it doesn't use leap seconds).
+But whatever.
+
+The point here is that we all agree with your point. There are a lot of systems
+that can't (or shouldn't) use local time and need access to a stable timebase
+like UTC time. The whole idea behind adding UTC_Offset was to provide *within
+Ada* a *portable* way to access the stable UTC time (since the popular systems
+all maintain a version of UTC time). And the problem here is that solution *does
+not work* in some corner cases.
+
+Now, clearly there are going to be some very hard real-time applications that
+will need their own custom timebase (GPS seems to be a good example). But this
+Ada solution is intended for the middle ground of applications that need
+reliable access to UTC time to the accuracy provided by the host system (for
+Windows and Unix that can be pretty good, as both systems can be hooked up to
+use NTP to sync their time), but don't want to hack around with local time and
+daylight savings time. One example is my web server, which is supposed to use
+UTC time in its timestamps - this isn't too critical, but I'd like a portable
+way to get it right.
+
+Unless you are saying that no application should ever use the host system
+version of UTC time, or anyone whose system ever runs an Ada program should have
+their system timezone set to UTC time, we need to fix this problem. Or don't you
+care about portable solutions any more??
+
+P.S. There aren't any TIMEZONE or DAYLIGHT_SAVINGS environment variables on my
+system either. :-) Doesn't mean anything; there is a TZ record that can be
+queried with a function, and surely the local time depends on it.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, May 20, 2010 9:02 PM
+
+> So it sounds like you agree we should
+> require "Calendar.Time" to preserve enough information so that
+> UTC_Time_Offset can be computed properly, by, for example, having a
+> bit indicating whether or not the value corresponds to daylight/summer
+> time.
+>
+> Or by using UTC time internally.
+
+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.
****************************************************************
Questions? Ask the ACAA Technical Agent