Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
From: John Cowan co...@mercury.ccil.org Cc: r6rs...@free-comp-shop.com, disc...@r6rs.org Ray Dillinger scripsit: On reflection I agree, and the current version (version 17) of TimeCowan now makes (current-posix-second) an integer. I have updated TimeAdvancedCowan to version 15 to reflect this change. I do not understand why this is so. Can you explain it for me? Because what happens at the subsecond level is not well-defined, and insofar as it is well-defined, it is not well-implemented. Theoretically the repeat happens exactly at the change from 23:60 to 23:61, but NTP does it several fractions of a second later. A nitpick or typo, but there is no 23:61. Seconds within a minute are numbered from zero (a very good convention) and so the sixty-first (leap) second is 23:59:60. Most days end with 23:59:59 and change to 00:00:00 of the next day one SI second later. I do not think there is any repeat in NTP. NTP transmits time as an integer count of seconds, a fractional second, and a leap second warning. It is up to the client (user) software to break this into hh:mm:ss form and insert the leap in the proper place or (more likely) torque it up. Posix has a repeat, the cause of all our grievances. -- Keith ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
r6rs...@free-comp-shop.com scripsit: A nitpick or typo, but there is no 23:61. A brain fart, rather. I do not think there is any repeat in NTP. NTP transmits time as an integer count of seconds, a fractional second, and a leap second warning. It is up to the client (user) software to break this into hh:mm:ss form and insert the leap in the proper place or (more likely) torque it up. I was referring not to NTP-the-protocol, but NTP-the-reference-implementation. See http://en.wikipedia.org/wiki/Unix_time#Non-synchronous_Network_Time_Protocol-based_variant . -- My confusion is rapidly waxing John Cowan For XML Schema's too taxing:co...@ccil.org I'd use DTDshttp://www.ccil.org/~cowan If they had local trees -- I think I best switch to RELAX NG. ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
From: John Cowan co...@mercury.ccil.org I do not think there is any repeat in NTP. I was referring not to NTP-the-protocol, but NTP-the-reference-implementation. See http://en.wikipedia.org/wiki/Unix_time#Non-synchronous_Network_Time_Protocol-based_variant . Yes, that is an excellent page for learning about the mess we are in. Note that it is headed Unix time. That's why I am reluctant to follow Unix too closely. With the count of seconds changed to an integer, I don't think I have any big worries. As I said, I am not attached to the names. I'll reply to your previous message after I think for a while. -- Keith ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
On Sun, 2010-12-19 at 00:28 -0500, John Cowan wrote: The main problem I still have is that the calendrical time is a real number[1], while the sub-second, physical time is an integer. I think this is exactly backward. I apologize for my previous proposal, which had integer physical time, it only distracted from the important thing. In order to avoid anomalous behaviour, the calendar time must be in integer seconds. On reflection I agree, and the current version (version 17) of TimeCowan now makes (current-posix-second) an integer. I have updated TimeAdvancedCowan to version 15 to reflect this change. I do not understand why this is so. Can you explain it for me? Bear ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
Modified proposal: (time-and-date) - return an integer count of non-leap seconds since the epoch. The epoch is given in standard. This can be used in calendar procedures. (seconds-on-timer) - return a real number, as accurate as reasonable, which is the time in seconds since the interval timer was reset. (time-of-reset) - an integer giving the time-and-date when the interval timer was reset (to zero). Maybe there should be a way to create timers, in which case those last two procedures need an argument (the timer). FWIW, I like this proposal. I think it captures the important semantics that we need in programming. A timer object is a very simple closure, and as a whole this strategy admits of several different implementation strategies depending on how the clock/counter works on the target device. On the naming of names, I think I'd go with a different name for the procedure time-and-date mentioned above. This is because the name time-and-date leads me to expect the actual values of years/months/days/hours/minutes/seconds to be broken out in the return value somehow. I would suggest an alternate name such as calendrical-seconds or calendrical-clock or something. As opposed to a different procedure absolute-seconds or absolute- clock having exactly the same semantics w/r/t an absolute count of all seconds including leap-seconds since the epoch. As to the behavior of calendrical-seconds during intervals that include leap seconds, I am very much in favor of: a) making any distinction in behavior optional, because some devices and operating systems don't update leap-seconds until reboot or repeated time-synch, or don't make them visible to programs during the programs' runtimes. b) allowing the scheme system to do whatever the underlying operating system does (including the weird Unix strategy of just slowing down the calendrical clock for some indeterminate period). c) If you have the information available and you want to go for canonically correct behavior, the preferred mechanism would be to have the clock of calendrical seconds just plain stop (milliseconds and all) for exactly one second while the leap second passes. Calendrical seconds are for when you want something to happen at an exact time relative to the consensus time and date in the future -- say, one-tenth of a second after the stock market opens on July first of 2012, when your options are tradeable. We can assume (I hope) that a trader who's making such demands of a system will make those demands of a system whose clock/calendar is kept tightly in synch with that of the market he wants to trade on, whatever the general strategy of the operating system underlying his system. Absolute seconds are for when you want something to happen exactly a particular number of seconds into the future -- say, at the exact moment when you expect Charon or Sedna to occlude a particular star so you can get a good measurement. And we can also assume (I hope) that an astronomer who's making such demands of a system will make those demands of a system whose absolute clock is kept in tight synch with the most accurate counter of seconds she can find (probably the atomic clock signal). Bear ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
On 27 November 2010 12:05, Marc Feeley fee...@iro.umontreal.ca wrote: On 2010-11-26, at 9:00 PM, John Cowan wrote: Marc Feeley scripsit: Please don't count time using milliseconds. It clutters my brain to have to remember a different unit of time than plain seconds. And yet the SI unit of mass is the kilogram. But I'll think about that. I'm not sure why you bring kilograms into the discussion. We're talking about time and the SI unit for time is the second. Legal time is expressed in terms of legal seconds, and I suppose we need legal seconds somewhere in the time library. Now, since a legal second may be either 1 or 2 SI seconds long, it might also be a good idea to sport a SI second or fraction thereof as an entity managed by the library, as something DISTINCT from legal seconds. If we can't agree on what fraction that shall be, because of portability issues, why not introduce an implementation-dependent unit jiffies or some such, and an implementation-dependent constant conversion rate jiffies-per-second, which could be an integer, fraction, real number, but hopefully not a complex number, and if possible exact. This would allow embedded implementation of Scheme to use whatever the hardware or OS clock provides them without further expensive conversion during time-sensitive operations. My modest proposal, for a Scheme implementation faithful to the spirit of Scheme, of doing The Right Thing at the expense of respect for convention, would be for a jiffy to be the Planck Unit of time: tP = 5.391 24(27) × 10^−44 s http://en.wikipedia.org/wiki/Planck_units If R7RS is to set the duration of a jiffy for all standard-compliant Scheme implementations, I vote for 1 jiffy = 1 tP [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] A fruitful discussion is a negotiation, out of which emerges meaning. Classic works are standards, and politeness is a protocol, to ease such negotiation. With a reasonably expressive language, neither is strictly needed, but both sure do help, and they are where the general progress happens. ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
On 2010-11-26, at 2:16 AM, John Cowan wrote: r6rs...@free-comp-shop.com scripsit: If fractions are allowed, why count milliseconds? Given that it should be easy to implement most dates as fixed-size objects, milliseconds seem like a good compromise between range and precision. Please don't count time using milliseconds. It clutters my brain to have to remember a different unit of time than plain seconds. Moreover, the choice of milliseconds, rather than microseconds or nanoseconds is purely an artifact of the current speed of computers. If you chose milliseconds as the unit of time in the hope of getting better resolution using integers you'll probably say 2 years from now milliseconds aren't precise enough for these fast CPUs, lets change the spec to use microseconds, and then 20 years from now darn! these CPUs have become fast! lets change the specs to use nanoseconds, etc. Integers shouldn't be used for measuring time points because applications need different resolutions. With a 64 bit float, you can represent a time interval of up to 3 months with a nanosecond resolution, and up to 266 years with a microsecond resolution. I don't see any practical reason for wanting more than this. Marc ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
r6rs...@free-comp-shop.com scripsit: In any case, most computer clocks aren't accurate to 1 part in 10^8, which is the discrepancy between Posix time and UTC time since the beginning of UTC. How many milliseconds is that? It's 24,000 ms out of the last 39 years, or approximately 1,230,720,117,120 ms. That is one part in 0.0002. I am not worried about precision, I am worried about correct arithmetic. I agree that subtracting one value of current-posix-millisecond from another has a rather small empirical probability of being off by 1000 ms, namely 1 in 10^-8. I have added a note to TimeCowan saying so. Note that 1 ms resolution does not necessarily imply 1 ms precision: in most Java implementations, you get 1 ms resolution but only 1 s precision. As for accuracy, typical computers with access to the Internet can be made accurate to about 35 ms, if carefully watched. You are *forbidding* an implementation to increment the clock before a leap second? Yes, absolutely. UTC time is readily available (except during leap seconds), TAI time is not. -- John Cowan co...@ccil.orghttp://ccil.org/~cowan No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friends or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee. --John Donne ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
From: John Cowan co...@mercury.ccil.org WG2 has decided to include a date-time arithmetic library in R7RS large Scheme, and I just finished writing up an API proposal for one. I decided to go for thorough rather than simple this time, and so I'm soliciting comments on it from sources outside WG2. The writeup is at http://trac.sacrideo.us/wg/wiki/TimeAdvancedCowan . Please use Reply All for your comments. Thanks. You say: an instant is a rational number representing a particular millisecond (or fraction thereof) If fractions are allowed, why count milliseconds? Just count seconds. If milliseconds are needed, multiply by 1000. You say: of the Posix epoch What does Posix have to do with a language that may be implemented on any OS? Use UTC. In particular, Posix torques up leap seconds. Trying to put both time-and-date *and* precise sub-second intervals into one number is a loser. In particular, does the current instant increment uniformly, or does it encode the current date? It can not do both, and it is unclear which you intend. My proposal: (time-of-day) - As close as possible to the UTC time encoded as an integer. It is incremented by 1 each ordinary (non-leap) second. It may or may not be incremented when a leap second passes. If it is not incremented then the same number will be given to the leap second as to the preceding second. In other words, sometimes the time is 23:59:59 for two seconds before the new year arrives. This ambiguity is the price of encoding the time-of-day as a single integer. The time-of-day may be incremented each second without knowing whether or not it is a leap second. Alternatively, it may be incremented only at the start of non-leap seconds, thus better tracking UTC. This is the preferred option. (tick-count) - An integer that is incremented at regular intervals as quickly as possible consistent with regularity. This number will never decrease while the program is running, but may be changed arbitrarily when the system is re-booted or equivalent. (ticks-per-second) - The tick rate of the above counter. This number does not change, but may differ from system to system. (epoch-of-zero-ticks) - the second, in time-of-day form, at the beginning of which the tick-count was zero. (extrapolated, the tick-count need not actually have been zero, indeed the computer need not have yet been built) From these data, the date and the time of day can be quickly computed with one second accuracy simply by calling (time-of-day). (But it will be off by one second for each time the implementation fails to non-count a leap second.) The time interval between two events while the program is running is: (let ((start (tick-count))) (wait) (/ (- (tick-count) start) (ticks-per-second))) and a sub-second timer that survives re-boots and agrees on several computers can be computed from the epoch-of-zero-ticks. (+ epoch-of-zero-ticks (/ (tick-count) (ticks-per-second))) Iff an uncounted leap second has intervened between the epoch-of-zero-ticks and the time the tick-count was taken then this number will differ by more than one from the (time-of-day). That is appropriate, because the time of day can not be used to compute exact time intervals without knowledge of the leap seconds. -- Keith PS: maybe the tick-count should be made a real number of seconds and renamed, getting rid of ticks-per-second. http://www.ucolick.org/~sla/leapsecs/timescales.html http://www.ucolick.org/~sla/leapsecs/onlinebib.html#POSIX http://en.wikipedia.org/wiki/Unix_time An account of bugs from messing up leap seconds: http://www.maa.org/mathland/mathland_7_21.html ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
r6rs...@free-comp-shop.com scripsit: If fractions are allowed, why count milliseconds? Given that it should be easy to implement most dates as fixed-size objects, milliseconds seem like a good compromise between range and precision. What does Posix have to do with a language that may be implemented on any OS? Use UTC. With what epoch? If you are to represent time as a number, there has to be a zero time, or epoch. There are various alternatives, such as the start of 1900 C.E. Gregorian (Common Lisp), the start of 4173 B.C.E. Julian (Julian days), the start of November 17, 1858 (modified Julian days), and lots more listed at http://en.wikipedia.org/wiki/Julian_day . But Posix-epoch time is available to 1 second precision on every modern system, so I chose it. It's also the only one close enough to the start of UTC timekeeping to make conversions possible. In particular, Posix torques up leap seconds. Yes, it does. But almost all computers do too. In any case, most computer clocks aren't accurate to 1 part in 10^8, which is the discrepancy between Posix time and UTC time since the beginning of UTC. Trying to put both time-and-date *and* precise sub-second intervals into one number is a loser. Why? 2^53 is a lot of range, and the further away from the present, the less precision we need or even can use, given the fundamental uncertainties about things like day length. It doesn't even make sense to ask about UTC time much before 1970. In particular, does the current instant increment uniformly, or does it encode the current date? It can not do both, and it is unclear which you intend. The latter, as Posix clock() does. It may or may not be incremented when a leap second passes. If it is not incremented then the same number will be given to the leap second as to the preceding second. In other words, sometimes the time is 23:59:59 for two seconds before the new year arrives. This ambiguity is the price of encoding the time-of-day as a single integer. The same as what I'm proposing, except that may or may not is just may not in my proposal. That way, at least every second except a leap second and the preceding second have fully specified instant values. In your proposal, there's no knowing what they mean, as some leap seconds but not others may be accounted for if the leap-second file (or other source) is out of date. (tick-count) - An integer that is incremented at regular intervals as quickly as possible consistent with regularity. This number will never decrease while the program is running, but may be changed arbitrarily when the system is re-booted or equivalent. (ticks-per-second) - The tick rate of the above counter. This number does not change, but may differ from system to system. (epoch-of-zero-ticks) - the second, in time-of-day form, at the beginning of which the tick-count was zero. (extrapolated, the tick-count need not actually have been zero, indeed the computer need not have yet been built) This is a good API, but functionally disjoint from what I'm dealing with now. -- John Cowanco...@ccil.orghttp://ccil.org/~cowan The whole of Gaul is quartered into three halves. --Julius Caesar ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
On Tue, 23 Nov 2010 16:05 -0500, John Cowan co...@mercury.ccil.org wrote: Christopher Chittleborough scripsit: (chronology-with-time-zone CHRONOLOGY TIMEZONE) Presumably a time zone name is a string. Say so explicitly? I actually do say what it can be: an offset in minutes from UTC, a string from the TZ database, or an implementation-defined alternative. Err, you don't use the word string, only name. I was thinking of something like: If the implementation supports the tz database, and timezone is a string equaling a time zone name defined by that database, ... This allows implementations to accept other strings, which is probably appropriate. (date-instant DATE) What happens if there is not enough info in DATE to uniquely determine an instant? Signal an error? Return #f? Added otherwise return #f. That's clearly the Right Thing to do. (date-field date FIELDNAME) Presumably FIELDNAME can be a symbol. Can it also be a string? That would require an extra lookup at run time. I think symbols are sufficient. Agreed. How about adding (a symbol) to the spec? Like this: Returns the numeric value of the field named fieldname (a symbol) within date ... (date-increment date fieldname increment) SNIP Excellent wording; adopted. The 'century' values in the ISO chronology don't seem right. If 1965 AD has century=19 in ISO, then 33 AD must have century=0 so 43 BC would have century=-1, not 0. Fixed. So (say) 43 BC is century -1 in Julian, Gregorian and ISO. Interesting. While the Joda Time API looks pretty good on brief reading, the Scheme version is much nicer -- yet another win for procedural APIs over class-based programming. Cheers ... Chris ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
Christopher Chittleborough scripsit: Err, you don't use the word string, only name. Fixed. Agreed. How about adding (a symbol) to the spec? Like this: Returns the numeric value of the field named fieldname (a symbol) Done. -- Well, I have news for our current leaders John Cowan and the leaders of tomorrow: the Bill ofco...@ccil.org Rights is not a frivolous luxury, in force http://www.ccil.org/~cowan only during times of peace and prosperity. We don't just push it to the side when the going gets tough. --Molly Ivins ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
This is a nice API for a subject that is much harder than generally realized. Here are a few minor quibbles: (chronology-with-time-zone CHRONOLOGY TIMEZONE) Presumably a time zone name is a string. Say so explicitly? (date-instant DATE) What happens if there is not enough info in DATE to uniquely determine an instant? Signal an error? Return #f? (date-field date FIELDNAME) Presumably FIELDNAME can be a symbol. Can it also be a string? (date-increment date fieldname increment) Suggestion: instead of talking about incrementing the specified *field*, put it in terms of incrementing the *date* by the units (month/day/hour/...) corresponding to fieldname. Something like: Constructs and returns a new date object which is later than DATE by INCREMENT of the units specified by FIELDNAME (earlier if INCREMENT negative). For example, (date-increment date 'day-of-month 7) adds one week. The 'century' values in the ISO chronology don't seem right. If 1965 AD has century=19 in ISO, then 33 AD must have century=0 so 43 BC would have century=-1, not 0. Cheers -- Chris Chittleborough ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
Hello everyone, (instant-date instance chronology) Constructs and returns a date object using chronology and corresponding to instant. This may be just a typo, but don't you mean instant instead of instance? (date-field date fieldname) Returns the value of the field named fieldname within date, or #f if there is no such field. Supposing that #f is a valid value for a field, don't we want to be able to tell apart no such field and the value is #f? (date-round date fieldname) (date-ceiling date fieldname) (date-floor date fieldname) (date-truncate date fieldname) Constructs and returns a new date object which is the same as date, but adjusted to the nearest integral value of fieldname using the round, ceiling, floor, or truncate functions. May this too have some effect on other fields than the one mentioned? Cheers, P! -- Français, English, 日本語, 한국어 ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Date and time arithmetic library proposal for R7RS large Scheme
Adrien Pied Piérard scripsit: This may be just a typo, but don't you mean instant instead of instance? Fixed. Supposing that #f is a valid value for a field, All date fields are numeric; see the Date objects section. (date-round date fieldname) May this too have some effect on other fields than the one mentioned? Fixed. -- What asininity could I have uttered John Cowan co...@ccil.org that they applaud me thus? http://www.ccil.org/~cowan --Phocion, Greek orator ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
