Re: RFC: DateTime::Format::Natural and "date_only" option
I would also mention that, at least this year, there are timezones such as in Egypt that have no time 00:00:00 on the day when the clocks move ahead - their timezone definition goes from 23:59:59 to 01:00:00 on that day. Steven Schubiger wrote: DateTime::Format::Natural currently does calculate its dates and times with an initial DateTime object received by "DateTime->now" (with timezone support). As a consequence thereof, many resulting final DateTime objects within DateTime::Format::Natural will retain for units that have not been altered the initial values. Clayton L. Scott suggested to introduce a "date_only" option, which would ignore (or reset) the time part for date-only strings. I intend to provide the names of the units to reset through according metadata entries in the grammar class. Later when post-processing data, the units would be resetted. Some examples from the adjusted and yet unreleased tests: * 27/5/1979 (without date_only: 27.05.1979 01:13:00) (with date_only: 27.05.1979 00:00:00) * yesterday (without date_only: 23.11.2006 01:13:08) (with date_only: 23.11.2006 00:00:00) * next hour (without date_only: 24.11.2006 02:13:08) (with date_only: 24.11.2006 02:00:00) * sunday 11:00 (without date_only: 26.11.2006 11:00:08) (with date_only: 26.11.2006 11:00:00) As mentioned above, I concur that it is worthwhile to implement (i.e., set the option per default and leave it open to the user to disable it), but I'm a bit unsure that "date_only" is the most suitable name for this new constructor option (given that it does not always reset just all time components). Suggestions and ideas welcome. Thanks, -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing DirectorFax: +1 763 786-8180 ApTest MinnesotaInet: sh...@aptest.com
Re: RFC: DateTime::Format::Natural and "date_only" option
Dave Rolsky wrote: Actually, the current behavior just seems broken. I'd suggest that you should _always_ truncate to the most specific parsed value. The current behavior is just confusing as heck in all the example up above. Absolutely agree. Your 'date_only' is pointless .. just return to the precision in the parsed value. If the input is "this time yesterday" (which would return down to the nanosecond) and you want the start of the hour, use ->truncate(to=>'hour') on the result. With strptime, I take a 'base datetime' which would give the existing behaviour of the Natural module .. it uses it to fill in the blanks, but your module shouldn't need that. Cheers! Rick Measham -- Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au
Re: RFC: DateTime::Format::Natural and "date_only" option
On Sat, 30 May 2009, Steven Schubiger wrote: DateTime::Format::Natural currently does calculate its dates and times with an initial DateTime object received by "DateTime->now" (with timezone support). As a consequence thereof, many resulting final DateTime objects within DateTime::Format::Natural will retain for units that have not been altered the initial values. Clayton L. Scott suggested to introduce a "date_only" option, which would ignore (or reset) the time part for date-only strings. I intend to provide the names of the units to reset through according metadata entries in the grammar class. Later when post-processing data, the units would be resetted. Some examples from the adjusted and yet unreleased tests: * 27/5/1979 (without date_only: 27.05.1979 01:13:00) (with date_only: 27.05.1979 00:00:00) * yesterday (without date_only: 23.11.2006 01:13:08) (with date_only: 23.11.2006 00:00:00) * next hour (without date_only: 24.11.2006 02:13:08) (with date_only: 24.11.2006 02:00:00) * sunday 11:00 (without date_only: 26.11.2006 11:00:08) (with date_only: 26.11.2006 11:00:00) As mentioned above, I concur that it is worthwhile to implement (i.e., set the option per default and leave it open to the user to disable it), but I'm a bit unsure that "date_only" is the most suitable name for this new constructor option (given that it does not always reset just all time components). Suggestions and ideas welcome. Actually, the current behavior just seems broken. I'd suggest that you should _always_ truncate to the most specific parsed value. The current behavior is just confusing as heck in all the example up above. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
RFC: DateTime::Format::Natural and "date_only" option
DateTime::Format::Natural currently does calculate its dates and times with an initial DateTime object received by "DateTime->now" (with timezone support). As a consequence thereof, many resulting final DateTime objects within DateTime::Format::Natural will retain for units that have not been altered the initial values. Clayton L. Scott suggested to introduce a "date_only" option, which would ignore (or reset) the time part for date-only strings. I intend to provide the names of the units to reset through according metadata entries in the grammar class. Later when post-processing data, the units would be resetted. Some examples from the adjusted and yet unreleased tests: * 27/5/1979 (without date_only: 27.05.1979 01:13:00) (with date_only: 27.05.1979 00:00:00) * yesterday (without date_only: 23.11.2006 01:13:08) (with date_only: 23.11.2006 00:00:00) * next hour (without date_only: 24.11.2006 02:13:08) (with date_only: 24.11.2006 02:00:00) * sunday 11:00 (without date_only: 26.11.2006 11:00:08) (with date_only: 26.11.2006 11:00:00) As mentioned above, I concur that it is worthwhile to implement (i.e., set the option per default and leave it open to the user to disable it), but I'm a bit unsure that "date_only" is the most suitable name for this new constructor option (given that it does not always reset just all time components). Suggestions and ideas welcome. Thanks,
