Re: Temporal.pod truncate
On Thu, 8 Apr 2010, Carl Mäsak wrote:
Among the cons: we lose the nice symmetry wherein :today clears all
values smaller than days, :toyear clears all values smaller than
years, etc. :tomonday is still pretty straightforward, but it's a
subtle category error.
Of course. What I really want is for weeks to start on Sunday, like
all the calendars around me seem to indicate that they do. Rather than
pushing my particular time-ideology on everyone else, I would like to
see a post-modern solution for the problem.
Having an internal variable like $[ to define the first day of the week
has turned out bad in the past, so I proposed this solution instead.
Apart from that, I wouldn't mind making the change. Though maybe we
should take a step backward and just remove :toweek altogether on
the grounds that it doesn't belong, and is more confusing than useful.
I agree that :toweek is confusing, but just because not everyone can
agree on the definition of week. But if you are writing a calendar
application, it is very useful. We measure time in weeks just as often
as we measure it in months, and weeks are a much less confusing time
interval than months are. Just because we prefer to _write_ dates
in terms of months doesn't mean weeks are any less valid of a time
interval. Anything besides year and day is rather artificial,
so maybe we should forget about months, weeks, hours, minutes and
seconds too. They should all be part of the calendar class, right?
On Fri, 9 Apr 2010, yary assumed:
indeed truncating to any day of the week can be implemented by user
trivially by adding/subtracting a constant number of days from the
Monday returned.
No, it's not a constant.
$sun = DateTime.new('2010-04-11').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-11').trunc( :tomonday ) # 2010-04-05
$sun - $mon == 6 days
$sun = DateTime.new('2010-04-12').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-12').trunc( :tomonday ) # 2010-04-12
$sun - $mon == -1 day
On Thu, 8 Apr 2010, Mark J. Reed wrote:
I think that :toweek should stay as-is; it truncates to whatever the
.week method returns, and that's Monday-based. It would be too
inconsistent for it to do anything else.
Agreed. That's why I asked for :tosunday
Asking for the latest prior Sunday or any other weekday is a useful
function, but it doesn't really have anything to do with 'truncation'.
Asking for the first of the month is truncating to an even more arbitrary
interval than a seven-day period, but we still call it truncation somehow.
The trouble with asking for the prior sunday, is that on sunday an
implementation of the prior() function will return a date 7 days prior to
today, while an implementation of the truncate() function will return
today.
Re: Temporal.pod truncate
On Tue, Apr 13, 2010 at 12:35 PM, John Williams willi...@tni.com wrote: Asking for the latest prior Sunday or any other weekday is a useful function, but it doesn't really have anything to do with 'truncation'. Asking for the first of the month is truncating to an even more arbitrary interval than a seven-day period, but we still call it truncation somehow.\ The size of the unit (and that size's variability) wasn't my point; it's that the unit is part of the fundamental identity of the date. A date is not a day; it's a particular name for a day. So when you truncate it, what you are removing precision from is the name. If the end result doesn't look like part of the name, it's not truncation. IMESHO, of course. The only reason you can truncate to the week in the proposed DateTime is because it includes support for the ISO week-based calendar, in additiion to the Gregorian. So just as you can truncate the Gregorian date April 13, 2010 to April 2010 or to 2010, you can truncate the ISO 8601 date 2010W15-2 to 2010W15 or to 2010. In each case the result of the truncation is the first day of the named period, which in the case of the ISO week calendar happens to be a Monday, but the truncation actually represents the whole period - just as truncating a real number to an integer yields a value that logically represents the entire half-open range from that integer to the next. You can imagine objects representing dates using other calendar systems. Today's Julian date March 31, 2010 could be truncated to March 2010 or to 2010; the Mayan long count 12.19.17.4.17 could be truncated to unial 12.19.17.4 or tun 12.19.17 or katun 12.19 or baktun 12. But unless I'm using a date object that has a baktun property, I wouldn't expect to be able to truncate to the baktun. The trouble with asking for the prior sunday, is that on sunday an implementation of the prior() function will return a date 7 days prior to today, while an implementation of the truncate() function will return today. True; that's why the Calendrica function is called kday-on-or-before instead of prior-kday - or actually, it may have both of those, with the difference you indicated. It's all about choosing the right name. :) Whatever you call it, it's a valuable function, I'm just arguing that it's not truncation unless you're talking about a calendar where you number Sunday-based weeks from a given epoch. -- Mark J. Reed markjr...@gmail.com
Re: Temporal.pod truncate
===
indeed truncating to any day of the week can be implemented by user
trivially by adding/subtracting a constant number of days from the
Monday returned.
No, it's not a constant.
$sun = DateTime.new('2010-04-11').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-11').trunc( :tomonday ) # 2010-04-05
$sun - $mon == 6 days
$sun = DateTime.new('2010-04-12').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-12').trunc( :tomonday ) # 2010-04-12
$sun - $mon == -1 day
===
You're not understanding me right- the addition subtraction have to
happen twice. (Ever had to truncate to an arbitrary multiple of 10 for
example?)
$sunday =DateTime.new(date_in_question+1 day).trunc( :tomonday) - 1 day
Unchecked versions of the setters (Re: Temporal.pod truncate)
Mark ():
I do think that an unchecked version of the setters is called for, one
that silently converts out-of-range values rather than throwing an
exception. That's not an easy thing to implement outside of the library
without duplicating all the range-checking code.
Hm, true (it's not an easy thing to implement setting of out-of-range
values outside of the library). But what would it be used for? What's
the advantage of having a date corresponding to no actual day?
What I have been considering is something along the lines of
DateTime.is_valid('2010-02-29'), that returns whether constructing
such a DateTime would be legal (in the sense of 'no exceptions
thrown'). It feels comforting to always leave a way for the API
consumer to find things out without resorting to CATCHing exceptions.
// Carl
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
The date still corresponds to an actual day. If I set it to Feb 31, I
should get back Mar 2 or 3 depending on the year. While I'm having
trouble thinking of a good specific example, it's a capability I've
taken advantage of many times, in holiday calculations, calendar
conversions, and such. I believe it's Python's datetime module that
has unchecked_* methods for the purpose.
Maybe in p6 the setters could do the correction if the exception is resumed?
On Friday, April 9, 2010, Carl Mäsak cma...@gmail.com wrote:
Mark ():
I do think that an unchecked version of the setters is called for, one
that silently converts out-of-range values rather than throwing an
exception. That's not an easy thing to implement outside of the library
without duplicating all the range-checking code.
Hm, true (it's not an easy thing to implement setting of out-of-range
values outside of the library). But what would it be used for? What's
the advantage of having a date corresponding to no actual day?
What I have been considering is something along the lines of
DateTime.is_valid('2010-02-29'), that returns whether constructing
such a DateTime would be legal (in the sense of 'no exceptions
thrown'). It feels comforting to always leave a way for the API
consumer to find things out without resorting to CATCHing exceptions.
// Carl
--
Mark J. Reed markjr...@gmail.com
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
Am 09.04.2010 13:34, schrieb Mark J. Reed: The date still corresponds to an actual day. If I set it to Feb 31, I should get back Mar 2 or 3 depending on the year. While I'm having trouble thinking of a good specific example, it's a capability I've taken advantage of many times, in holiday calculations, calendar conversions, and such. I believe it's Python's datetime module that has unchecked_* methods for the purpose. Maybe in p6 the setters could do the correction if the exception is resumed? Too much magic. Sounds to me like you want a named parameter for a setter, like :force or :unchecked or so. Anyway, I'm not sure such a feature needs to be in the core, at least not in 6.0.0. Cheers, Moritz
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
On 4/9/2010 4:53 AM, Moritz Lenz wrote: Am 09.04.2010 13:34, schrieb Mark J. Reed: The date still corresponds to an actual day. If I set it to Feb 31, I should get back Mar 2 or 3 depending on the year. While I'm having trouble thinking of a good specific example, it's a capability I've taken advantage of many times, in holiday calculations, calendar conversions, and such. I believe it's Python's datetime module that has unchecked_* methods for the purpose. Maybe in p6 the setters could do the correction if the exception is resumed? Too much magic. Sounds to me like you want a named parameter for a setter, like :force or :unchecked or so. Anyway, I'm not sure such a feature needs to be in the core, at least not in 6.0.0. Unless forming a duration based on various units is really simple, un-checked setters makes generating new Instants from one ones simpler. It is very useful to be able to implement the operators tomorrow, yesterday, thirty_days_from_now, twelve_hours_ago, etc, just by incrementing through the appropriate setter, especially in one-liners. -- m...@biggar.org mark.a.big...@comcast.net
Re: Temporal.pod truncate
On Thu, Apr 8, 2010 at 7:26 PM, Mark J. Reed markjr...@gmail.com wrote: I think that :toweek should stay as-is; it truncates to whatever the .week method returns, and that's Monday-based. It would be too inconsistent for it to do anything else. Asking for the latest prior Sunday or any other weekday is a useful function, but it doesn't really have anything to do with 'truncation'. indeed truncating to any day of the week can be implemented by user trivially by adding/subtracting a constant number of days from the Monday returned. I do think that an unchecked version of the setters is called for, one that silently converts out-of-range values rather than throwing an exception. That's not an easy thing to implement outside of the library without duplicating all the range-checking code. Would it be unreasonably hackish to get a converted from out-of-range date out of the exception?
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
Especially since we're not ignoring leap seconds; in UTC, 30 days is not always 30*86400 atomic seconds. Other units are more obviously variable-length, but you have to be careful. If you increment one month at a time with autocorrect, 4 months from Jan 31 gets you Jun 2 or 3 instead of May 31. On Friday, April 9, 2010, Mark Biggar m...@biggar.org wrote: On 4/9/2010 4:53 AM, Moritz Lenz wrote: Am 09.04.2010 13:34, schrieb Mark J. Reed: The date still corresponds to an actual day. If I set it to Feb 31, I should get back Mar 2 or 3 depending on the year. While I'm having trouble thinking of a good specific example, it's a capability I've taken advantage of many times, in holiday calculations, calendar conversions, and such. I believe it's Python's datetime module that has unchecked_* methods for the purpose. Maybe in p6 the setters could do the correction if the exception is resumed? Too much magic. Sounds to me like you want a named parameter for a setter, like :force or :unchecked or so. Anyway, I'm not sure such a feature needs to be in the core, at least not in 6.0.0. Unless forming a duration based on various units is really simple, un-checked setters makes generating new Instants from one ones simpler. It is very useful to be able to implement the operators tomorrow, yesterday, thirty_days_from_now, twelve_hours_ago, etc, just by incrementing through the appropriate setter, especially in one-liners. -- m...@biggar.org mark.a.big...@comcast.net -- Mark J. Reed markjr...@gmail.com
Temporal.pod truncate
Small feature request: $dt.truncate( :toweek ); is somewhat ambiguous, since some people start their week on Sunday, while the module truncates to Monday. Would you consider a less ambiguous week truncation? $dt.truncate( :tosunday ); $dt.truncate( :tomonday ); ~ John Williams
Re: Temporal.pod truncate
John (): Small feature request: $dt.truncate( :toweek ); is somewhat ambiguous, since some people start their week on Sunday, while the module truncates to Monday. Would you consider a less ambiguous week truncation? $dt.truncate( :tosunday ); $dt.truncate( :tomonday ); I had the same thought, actually. I see both pros and cons. Among the pros: we'll cater to both the Sunday-starters and Monday-starters out there, just as you say. Among the cons: we lose the nice symmetry wherein :today clears all values smaller than days, :toyear clears all values smaller than years, etc. :tomonday is still pretty straightforward, but it's a subtle category error. Apart from that, I wouldn't mind making the change. Though maybe we should take a step backward and just remove :toweek altogether on the grounds that it doesn't belong, and is more confusing than useful. :) // Carl
Re: Temporal.pod truncate
I think that :toweek should stay as-is; it truncates to whatever the .week method returns, and that's Monday-based. It would be too inconsistent for it to do anything else. Asking for the latest prior Sunday or any other weekday is a useful function, but it doesn't really have anything to do with 'truncation'. I do think that an unchecked version of the setters is called for, one that silently converts out-of-range values rather than throwing an exception. That's not an easy thing to implement outside of the library without duplicating all the range-checking code. On Thu, Apr 8, 2010 at 6:09 PM, Carl Mäsak cma...@gmail.com wrote: John (): Small feature request: $dt.truncate( :toweek ); is somewhat ambiguous, since some people start their week on Sunday, while the module truncates to Monday. Would you consider a less ambiguous week truncation? $dt.truncate( :tosunday ); $dt.truncate( :tomonday ); d; I had the same thought, actually. I see both pros and cons. Among the pros: we'll cater to both the Sunday-starters and Monday-starters out there, just as you say. Among the cons: we lose the nice symmetry wherein :today clears all values smaller than days, :toyear clears all values smaller than years, etc. :tomonday is still pretty straightforward, but it's a subtle category error. Apart from that, I wouldn't mind making the change. Though maybe we should take a step backward and just remove :toweek altogether on the grounds that it doesn't belong, and is more confusing than useful. :) // Carl -- Mark J. Reed markjr...@gmail.com
