* Ada.Calendar.Time_Zones @ 2008-08-04 9:31 Dmitry A. Kazakov 2008-08-04 13:56 ` Ada.Calendar.Time_Zones google1 2008-08-04 22:12 ` Ada.Calendar.Time_Zones Randy Brukardt 0 siblings, 2 replies; 13+ messages in thread From: Dmitry A. Kazakov @ 2008-08-04 9:31 UTC (permalink / raw) Does anybody know the meaning of the result returned by UTC_Time_Offset? RM says: "Returns, as a number of minutes, the difference between the implementation-defined time zone of Calendar, and UTC time, at the time Date." This is ill-defined. Political time has overlapping intervals in presence of daylight saving time, when the clock is adjusted backwards. The overlapping time interval has two differences to the UTC time. So which one is returned by UTC_Time_Offset? Furthermore, some intervals are missing in political time. That is when the clock is adjusted forward. What is the difference then? Unknown_Zone_Error? P.S. Why not to simply provide Ada.UTC_Time (with conversion to Ada.Calendar.Time) instead of this mess? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-04 9:31 Ada.Calendar.Time_Zones Dmitry A. Kazakov @ 2008-08-04 13:56 ` google1 2008-08-04 14:57 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-04 22:12 ` Ada.Calendar.Time_Zones Randy Brukardt 1 sibling, 1 reply; 13+ messages in thread From: google1 @ 2008-08-04 13:56 UTC (permalink / raw) On Aug 4, 4:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > Does anybody know the meaning of the result returned by UTC_Time_Offset? RM > says: > > "Returns, as a number of minutes, the difference between the > implementation-defined time zone of Calendar, and UTC time, at the time > Date." > > This is ill-defined. Political time has overlapping intervals in presence > of daylight saving time, when the clock is adjusted backwards. That definition accounts for DST shifts. It says "at the time Date," which means that if the date falls into a period where the locale is in a DST shift, it will return the DST offset. Otherwise, it will return the ST offset. Unix systems keep information about historic and future (planned) shifts in their locale's time offset in the tzdata database. I suspect Windows and other systems have something similar, so by using that database it is possible to find the time offset for any point in the past, as well as predicted ones for points in the future. > The overlapping time interval has two differences to the UTC time. So which > one is returned by UTC_Time_Offset? > > Furthermore, some intervals are missing in political time. That is when the > clock is adjusted forward. What is the difference then? Unknown_Zone_Error? I'm not aware of what is typically done in such areas. I would suspect that each differing opinion has its own locale, and the computer will be configured to use one locale or the other. > P.S. Why not to simply provide Ada.UTC_Time (with conversion to > Ada.Calendar.Time) instead of this mess? Well I don't think it's a mess. You can convert to UTC or any other timezone very easily by changing the offset. Most internet communication deals in dates via a UTC offset (typically in the form +/-HHMM but it's easy to convert from that to +/-minutes). I can say that dealing with date stamps in the Basil project would have been *far* more difficult using Ada 95 dates, which are ignorant of differing timezones. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-04 13:56 ` Ada.Calendar.Time_Zones google1 @ 2008-08-04 14:57 ` Dmitry A. Kazakov 2008-08-04 20:56 ` Ada.Calendar.Time_Zones Maciej Sobczak 0 siblings, 1 reply; 13+ messages in thread From: Dmitry A. Kazakov @ 2008-08-04 14:57 UTC (permalink / raw) On Mon, 4 Aug 2008 06:56:56 -0700 (PDT), google1@hafdconsulting.com wrote: > On Aug 4, 4:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> Does anybody know the meaning of the result returned by UTC_Time_Offset? RM >> says: >> >> "Returns, as a number of minutes, the difference between the >> implementation-defined time zone of Calendar, and UTC time, at the time >> Date." >> >> This is ill-defined. Political time has overlapping intervals in presence >> of daylight saving time, when the clock is adjusted backwards. > > That definition accounts for DST shifts. It says "at the time > Date," which means that if the date falls into a period where > the locale is in a DST shift, it will return the DST offset. > Otherwise, it will return the ST offset. Consider 1 Oct, 00:30 on the clock. Is it 30 minutes *after* the shift (already ST) or 30 minutes *before* the shift (still DST)? > Well I don't think it's a mess. You can convert to UTC or any other > timezone very easily by changing the offset. So far, it is unclear how to do this. The same problem has Ada.Calendar.Arithmetic. When Difference is calculated between two dates within the overlapping hour there are two results. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-04 14:57 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov @ 2008-08-04 20:56 ` Maciej Sobczak 0 siblings, 0 replies; 13+ messages in thread From: Maciej Sobczak @ 2008-08-04 20:56 UTC (permalink / raw) On 4 Sie, 16:57, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > When Difference is calculated between two dates > within the overlapping hour there are two results. As long as both are correct, what is the problem? ;-) -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-04 9:31 Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-04 13:56 ` Ada.Calendar.Time_Zones google1 @ 2008-08-04 22:12 ` Randy Brukardt 2008-08-05 9:10 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 1 sibling, 1 reply; 13+ messages in thread From: Randy Brukardt @ 2008-08-04 22:12 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net... > Does anybody know the meaning of the result returned by UTC_Time_Offset? It's as the RM says. You've asked this question here before, and if you want a useful answer, you need to ask the ARG by sending a question to Ada-Comment. It's pointless to ask the question here more than once; if you don't care enough to ask the question on Ada-Comment, then you are just trolling. Please don't; we have enough of that here as it is. ... > P.S. Why not to simply provide Ada.UTC_Time (with conversion to > Ada.Calendar.Time) instead of this mess? The short answer is that it wouldn't provide any support for time zones other than UTC and (unspecified) local time zone. My original idea was that there would be a UTC_Clock function that returned the correct time. In particular, I viewed a value of Ada.Calendar.Time as an absolute time without any knowledge of a time zone. Specifically, value of Ada.Calendar.Time would represent a value like 09:53:00 August 31 2008 with no particular time zone implied. That means that all of the other operations make sense with no extra interpretation. However, that model didn't fly with some members of the ARG: they view a value of Ada.Calendar.Time as a particular political time. In that view, a UTC_Clock and Ada.Calendar.Clock would always return the same (logical) value, and thus the split and formatting routines would always return the same answer (the political time). Thus some method is needed to tell the value what time zone the value is intrepreted to be in. I think we screwed up by using a visible offset value, however; it should have been a private type that could work any way the implementation wanted. Particularly, there should have been constants for UTC and local time, and then an implementation could add more if they wanted. It's pretty obvious, though, that there is no way to do this correctly unless the time type is based on UTC (time-zone-less) time. And because of compatibility concerns, the only way to do that is to completely junk Ada.Calendar and start over, duplicating essentially everything. You're probably right that we should have done that, but it would always be a tough sell (lots of people would say that Ada.Calendar is "good enough") -- which is why you need to ask this question directly to the ARG. (And get as many people as possible to support it, too.) I alone could never produce critical mass on this topic. Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-04 22:12 ` Ada.Calendar.Time_Zones Randy Brukardt @ 2008-08-05 9:10 ` Dmitry A. Kazakov 2008-08-07 2:52 ` Ada.Calendar.Time_Zones Randy Brukardt 0 siblings, 1 reply; 13+ messages in thread From: Dmitry A. Kazakov @ 2008-08-05 9:10 UTC (permalink / raw) On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net... >> Does anybody know the meaning of the result returned by UTC_Time_Offset? > > It's as the RM says. But how to translate what it says into concrete numbers: UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =? OK, I am posting that to Ada comments as you suggested. > It's pretty obvious, though, that there is no way to do this correctly > unless the time type is based on UTC (time-zone-less) time. And because of > compatibility concerns, the only way to do that is to completely junk > Ada.Calendar and start over, duplicating essentially everything. You're > probably right that we should have done that, but it would always be a tough > sell (lots of people would say that Ada.Calendar is "good enough") -- which > is why you need to ask this question directly to the ARG. (And get as many > people as possible to support it, too.) I alone could never produce critical > mass on this topic. I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic, Ada.Calendar.Formatting are all new packages. All of them have an inconsistent semantics, because Time_Of is necessarily inconsistent [*]. Zone offset is simply not a function of the local time. It is of the UTC time. -------- * without additional parameters. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-05 9:10 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov @ 2008-08-07 2:52 ` Randy Brukardt 2008-08-07 8:27 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 0 siblings, 1 reply; 13+ messages in thread From: Randy Brukardt @ 2008-08-07 2:52 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net... > On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net... >>> Does anybody know the meaning of the result returned by UTC_Time_Offset? >> >> It's as the RM says. > > But how to translate what it says into concrete numbers: > > UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =? > > OK, I am posting that to Ada comments as you suggested. I don't think the RM answers your question, which technically means that it is unspecified. It is reasonable to ask if it *ought* to be unspecified, which is why I asked you to ask the ARG. >> It's pretty obvious, though, that there is no way to do this correctly >> unless the time type is based on UTC (time-zone-less) time. And because >> of >> compatibility concerns, the only way to do that is to completely junk >> Ada.Calendar and start over, duplicating essentially everything. You're >> probably right that we should have done that, but it would always be a >> tough >> sell (lots of people would say that Ada.Calendar is "good enough") -- >> which >> is why you need to ask this question directly to the ARG. (And get as >> many >> people as possible to support it, too.) I alone could never produce >> critical >> mass on this topic. > > I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic, > Ada.Calendar.Formatting are all new packages. All of them have an > inconsistent semantics, because Time_Of is necessarily inconsistent [*]. > Zone offset is simply not a function of the local time. It is of the UTC > time. You'd have to completely duplicate the contents of Ada.Calendar using a new, very similar time type that is based on UTC. That would have been a hard sell (even if it would have made more sense, since Ada.Calendar.Arithmetic probably would have been included directly as part of it). Your examples make it clear that we should have done that, but we obviously failed to notice that what we did instead doesn't quite work. The real question is whether the hole is important enough to try to fix (given that the fix is going require adding a lot more mechanism). That's a question I can't answer. Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-07 2:52 ` Ada.Calendar.Time_Zones Randy Brukardt @ 2008-08-07 8:27 ` Dmitry A. Kazakov 2008-08-07 22:47 ` Ada.Calendar.Time_Zones Randy Brukardt 0 siblings, 1 reply; 13+ messages in thread From: Dmitry A. Kazakov @ 2008-08-07 8:27 UTC (permalink / raw) On Wed, 6 Aug 2008 21:52:53 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:3jxnfgd6m2ff.ca8crnn387m3.dlg@40tude.net... >> On Mon, 4 Aug 2008 17:12:38 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:1rm26vi0mz4sv.1kfhdnswhcrqa.dlg@40tude.net... >>>> Does anybody know the meaning of the result returned by UTC_Time_Offset? >>> >>> It's as the RM says. >> >> But how to translate what it says into concrete numbers: >> >> UTC_Time_Offset (Ada.Calendar.Time_Of (2008, 26, 10, 2.5*60.0*60.0)); =? >> >> OK, I am posting that to Ada comments as you suggested. > > I don't think the RM answers your question, which technically means that it > is unspecified. Which perplexes me much. How could it happen that an Ada library function has undefined behavior. > It is reasonable to ask if it *ought* to be unspecified, > which is why I asked you to ask the ARG. Yes, I did. >>> It's pretty obvious, though, that there is no way to do this correctly >>> unless the time type is based on UTC (time-zone-less) time. And because >>> of >>> compatibility concerns, the only way to do that is to completely junk >>> Ada.Calendar and start over, duplicating essentially everything. You're >>> probably right that we should have done that, but it would always be a >>> tough >>> sell (lots of people would say that Ada.Calendar is "good enough") -- >>> which >>> is why you need to ask this question directly to the ARG. (And get as >>> many >>> people as possible to support it, too.) I alone could never produce >>> critical >>> mass on this topic. >> >> I don't understand this. Ada.Calendar.Time_Zones, Ada.Calendar.Arithmetic, >> Ada.Calendar.Formatting are all new packages. All of them have an >> inconsistent semantics, because Time_Of is necessarily inconsistent [*]. >> Zone offset is simply not a function of the local time. It is of the UTC >> time. > > You'd have to completely duplicate the contents of Ada.Calendar using a new, > very similar time type that is based on UTC. Hmm, is Ada.Calendar big? Anyway one didn't hesitate to duplicate most of it in Ada.Calendar.Arithmetic. But all that stuff like Time_Of etc is not really needed with UTC_Time. The package should provide Clock, +, -, <, <=, >, >=: package Ada.UTC_Time is type UTC_Time is private; function Clock return UTC_Time; function "+" (Left : UTC_Time; Right : Duration) return UTC_Time; function "+" (Left : Duration; Right : UTC_Time) return UTC_Time; function "-" (Left : UTC_Time; Right : Duration) return UTC_Time; function "-" (Left : UTC_Time; UTC_Time : Time) return Duration; function "<" (Left, Right : UTC_Time) return Boolean; function "<="(Left, Right : UTC_Time) return Boolean; function ">" (Left, Right : UTC_Time) return Boolean; function ">="(Left, Right : UTC_Time) return Boolean; end Ada.UTC_Time; That's it. Then: package Ada.UTC_Time.Time_Zones is type Time_Offset is range -28*60 .. 28*60; -- This is well-defined function UTC_Time_Offset (Date : UTC_Time := Clock) return Time_Offset; function To_Calendar_Time (Time : UTC_Time; Time_Zone) return Time; function To_Calendar_Time (Time : UTC_Time; Time_Zone; Time_Offset) return Time; -- Time Zone is always required for the backward conversion function To_UTC_Time (Time : Time; Time_Zone; Time_Offset) return Time; end Ada.UTC_Time.Time_Zones; I would also like to see conversions between Ada.Real_Time.Time and UTC_Time. > The real question is whether the hole is important enough to try to fix > (given that the fix is going require adding a lot more mechanism). That's a > question I can't answer. Our problem is that we need to exchange time-stamped data with the outside world. So we have to convert UTC forth and back to Ada.Real_Time.Time. It is to expect that the system might become out of service for when the clock is adjusted. Considering similar cases, like air flight traffic control systems dealing with GPS clock etc, I wonder how they would handle that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-07 8:27 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov @ 2008-08-07 22:47 ` Randy Brukardt 2008-08-08 8:48 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 0 siblings, 1 reply; 13+ messages in thread From: Randy Brukardt @ 2008-08-07 22:47 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net... ... > But all that stuff like Time_Of etc is not really needed with UTC_Time. > The > package should provide Clock, +, -, <, <=, >, >=: I don't see how that could work. How would you display or create a UTC time? I find that most of the time you either want to use one or the other (that is, either UTC time or local time) exclusively in a single program. Converting to local time wouldn't work since it would change the time zone. Anyway, we should have this discussion on Ada-Comment, where it will get recorded and attached to the eventual AI on the topic. Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-07 22:47 ` Ada.Calendar.Time_Zones Randy Brukardt @ 2008-08-08 8:48 ` Dmitry A. Kazakov 2008-08-09 2:09 ` Ada.Calendar.Time_Zones Randy Brukardt 0 siblings, 1 reply; 13+ messages in thread From: Dmitry A. Kazakov @ 2008-08-08 8:48 UTC (permalink / raw) On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net... > ... >> But all that stuff like Time_Of etc is not really needed with UTC_Time. >> The package should provide Clock, +, -, <, <=, >, >=: > > I don't see how that could work. How would you display or create a UTC time? No problem: T : Ada.UTC_Time.Time := ...; P : Ada.Calendar.Time := To_Calendar_Time (T); P is the political time corresponding to T, it is well-defined for each T. P can be used in Ada.Calendar.Split to display T as: August 08, 2008 10:18 (Berlin time) When used in Ada.Calendar.Formatting.Split with Time_Zone => UTC_Time_Offset (T) the display could be: August 08, 2008 09:18 (UTC time) Creating UTC time from UTC's Y/M/D/S should go as follows: To_UTC_Time (Ada.Calendar.Formatting.Time_Of (Y/M/D/S, 0), 0); > Anyway, we should have this discussion on Ada-Comment, where it will get > recorded and attached to the eventual AI on the topic. Has the proposal any chance to made it? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-08 8:48 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov @ 2008-08-09 2:09 ` Randy Brukardt 2008-08-09 8:04 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 0 siblings, 1 reply; 13+ messages in thread From: Randy Brukardt @ 2008-08-09 2:09 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net... > On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net... >> ... >>> But all that stuff like Time_Of etc is not really needed with UTC_Time. >>> The package should provide Clock, +, -, <, <=, >, >=: >> >> I don't see how that could work. How would you display or create a UTC >> time? > > No problem: > > T : Ada.UTC_Time.Time := ...; > P : Ada.Calendar.Time := To_Calendar_Time (T); > > P is the political time corresponding to T, it is well-defined for each T. > P can be used in Ada.Calendar.Split to display T as: > > August 08, 2008 10:18 (Berlin time) > > When used in Ada.Calendar.Formatting.Split with > > Time_Zone => UTC_Time_Offset (T) > > the display could be: > > August 08, 2008 09:18 (UTC time) Sorry, this doesn't make any sense. Your original point, boiled down, is that it is never safe to convert from political time to UTC (because of the overlaps and holes). But then you go ahead and do exactly that. You could probably make it work if you somehow required Ada.Calendar.Time to store UTC time + a time zone converter (that is, it isn't really political time). But that would force a change in representation for most compiler's Ada.Calendar.Time type, and most likely an increase in size as well. That would really mess up existing programs that store binary representations of Time (as Janus/Ada does internally). In any case, if you were willing to require that, the current specification would work just fine for UTC time (because you could always get the UTC time directly from the record). In which case there is no problem, so we don't need an additional mechanism. ... >> Anyway, we should have this discussion on Ada-Comment, where it will get >> recorded and attached to the eventual AI on the topic. > > Has the proposal any chance to made it? I have no idea. I intend to put the mail and question into an AI and thus it will be on the agenda in the future. Beyond that I cannot say. I'm sure this exact proposal has no chance because it doesn't fix anything. But a proposal that does fix something may be a different animal. Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-09 2:09 ` Ada.Calendar.Time_Zones Randy Brukardt @ 2008-08-09 8:04 ` Dmitry A. Kazakov 2008-08-14 0:20 ` Ada.Calendar.Time_Zones Randy Brukardt 0 siblings, 1 reply; 13+ messages in thread From: Dmitry A. Kazakov @ 2008-08-09 8:04 UTC (permalink / raw) On Fri, 8 Aug 2008 21:09:42 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:aht87sie2uac$.ke09vcui32dj.dlg@40tude.net... >> On Thu, 7 Aug 2008 17:47:41 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:61migfnkb0sm.8wytouvj8o4f.dlg@40tude.net... >>> ... >>>> But all that stuff like Time_Of etc is not really needed with UTC_Time. >>>> The package should provide Clock, +, -, <, <=, >, >=: >>> >>> I don't see how that could work. How would you display or create a UTC >>> time? >> >> No problem: >> >> T : Ada.UTC_Time.Time := ...; >> P : Ada.Calendar.Time := To_Calendar_Time (T); >> >> P is the political time corresponding to T, it is well-defined for each T. >> P can be used in Ada.Calendar.Split to display T as: >> >> August 08, 2008 10:18 (Berlin time) >> >> When used in Ada.Calendar.Formatting.Split with >> >> Time_Zone => UTC_Time_Offset (T) >> >> the display could be: >> >> August 08, 2008 09:18 (UTC time) > > Sorry, this doesn't make any sense. Your original point, boiled down, is > that it is never safe to convert from political time to UTC (because of the > overlaps and holes). But then you go ahead and do exactly that. It is safe in this case because it uses an external zone offset. The conversion is unsafe when an attempt is made to determine the offset from the political time itself. That is inconsistent. But when the offset is determined by the UTC time, then everything is fine. > In any case, if you were willing to require that, the current specification > would work just fine for UTC time (because you could always get the UTC time > directly from the record). In which case there is no problem, so we don't > need an additional mechanism. Yes, this is what GNAT does, at least under Windows. My proposal would allow to have Ada.Calendar.Time really skewed as politicians always whished (:-)). E.g. T : Time := Time_Of (2008, 10, 28, 1.5*3600.0); -- 1h before the skew then T1 := T + 1.0*3600.0; -- 28.10.2008 02:30 before skew T2 := T + 2.0*3600.0; -- 28.10.2008 02:30 after skew T1 = T2 -- Political arithmetic! A time defined this way will still be convertible forth and back to UTC time, if you know the time offset. That is 1h for T1 and 2h for T2. ----------- But in any case, RM should clarify what it means under political time. I.e. whether T1 = T2 (= truly political time), or not (= hidden UTC time). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ada.Calendar.Time_Zones 2008-08-09 8:04 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov @ 2008-08-14 0:20 ` Randy Brukardt 0 siblings, 0 replies; 13+ messages in thread From: Randy Brukardt @ 2008-08-14 0:20 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:18iqoye18iuzu$.jz3bz3dssmhe.dlg@40tude.net... ... > But in any case, RM should clarify what it means under political time. > I.e. > whether T1 = T2 (= truly political time), or not (= hidden UTC time). We purposely did not answer that question, because compilers do not agree and the only way to get any agreement at all was to leave it unsatisfied. Most of the compilers do the former (Janus/Ada certainly does), but there was a vocal minority that wanted the latter be supported. You should add this question to the Ada-Comment thread (with an appropriate example), so we can have that fight all over again. It's important that you have shown that it may have semantic effects (we were convinced it did not, so we decided not to answer the question). Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-08-14 0:20 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-08-04 9:31 Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-04 13:56 ` Ada.Calendar.Time_Zones google1 2008-08-04 14:57 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-04 20:56 ` Ada.Calendar.Time_Zones Maciej Sobczak 2008-08-04 22:12 ` Ada.Calendar.Time_Zones Randy Brukardt 2008-08-05 9:10 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-07 2:52 ` Ada.Calendar.Time_Zones Randy Brukardt 2008-08-07 8:27 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-07 22:47 ` Ada.Calendar.Time_Zones Randy Brukardt 2008-08-08 8:48 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-09 2:09 ` Ada.Calendar.Time_Zones Randy Brukardt 2008-08-09 8:04 ` Ada.Calendar.Time_Zones Dmitry A. Kazakov 2008-08-14 0:20 ` Ada.Calendar.Time_Zones Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox