Re: Standalone Times?
On Sunday, June 22, 2003 Eugene van der Pijll wrote: >Bruce Van Allen schreef: >> From a string in the form MM, the DT::F::ISO8601 parser >> should return a DT object identical to the DateTime object >> instantiated from >> $dt = DateTime->new( >> year => 2003, >> month => 6. >> ); > >No. > >Let me show you a couple of ISO8601 time intervals, and my >interpretation of them: > >Tomorrow, I have a meeting on "2003-06-22T15/17". I would expect this >meeting to start at 15:00:00, and to end at 17:00:00. That is, both >start and end times are rounded down. > >This year, the Tour de France is "2003-07-05/2003-07-27". Cyclist >shouldn't expect to go shopping in Paris on the 27th, as they will be >busy until late that day (besides, it's a Sunday and the shops will be >closed). The best interpretation of that end date is something like >2003-07-27T23:59:59 or 2003-07-28T00:00:00. That is, end date is rounded >up (and the start date is rounded down). > >Julius Ceasar lived "-0099/-0043". The starting date should here be >interpreted as "somewhere in 100BC, and the end date should be >interpreted as "the ides of March 44BC". Setting both to Jan 1st would >be simply wrong. Got it. I was seeing -MM only as a truncated date. Seems a challenge to devise rules for this. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Standalone Times?
On Sunday, June 22, 2003 Dave Rolsky wrote: >On Sat, 21 Jun 2003, Bruce Van Allen wrote: >> The point of DT::Format::XXX is parsing and formatting: >> - to return a DT object if given an XXX-formatted date/time string; >>and >> - to return an XXX-formatted string from a DT object. > >Well, the formats can also include formats for durations, recurrences, >etc. ISO has duration formats, and iCal has durations, periods (aka >spans), and recurrences. > Yes. I should have said "The BASIC point of DT::Format:XXX ..." The other formats are specific to the system to be parsed/formatted (MySQL, iCal, etc.). The context was a question that seemed to be veering away from the DT::F API, by not returning a DT object from parsing a string. (Unless I misunderstood.) - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Standalone Times?
On Sun, Jun 22, 2003 at 04:47:42AM +0200, Eugene van der Pijll wrote: > > If YY really is the century, you should probably return Jan 1st, 1901 > when given 20... The example given in the spec says that given "12 April 1985" YY gives 19. So they are being a little loose with the word century... -ben
Re: Standalone Times?
> Dave Rolsky schreef: > > It's really hard for me to think of a case where you would not know the > > expected precision in advance. It's usually true that you do know the precision in advance (not always) but not ALL handling of time involves knowing the year. On Sun, 22 Jun 2003, Eugene van der Pijll wrote: > One file can contain dates of varying precision, and you can't tell the > precision of an individual date in advance. If DT::F::ISO8601 returns > a DateTime object of 1234-01-01T00:00:00 for the ISO8601 strings "1234", > "1234-01" and "1234-01-01", you have a problem. How about a precision mask specifying which fields are valid/accurate? -J --
Re: Standalone Times?
Dave Rolsky schreef: > Here's the thing. Yes, the object would contain more precision than the > original data, _but_ presumably if you are only exchanging "year and > month" data, then you will only look at the year and month of the returned > object. > > It's really hard for me to think of a case where you would not know the > expected precision in advance. Think for example of history or genealogy. Of some events we know the full date, of others only the month or the year, or even the century (e.g. the birth of King Arthur was in 04). And some dates will be expressed as time intervals, either because they are really date ranges (World War II: from 1939 to 1945) or because they are only approximately known (King Arthur again: born between 450 and 500). One file can contain dates of varying precision, and you can't tell the precision of an individual date in advance. If DT::F::ISO8601 returns a DateTime object of 1234-01-01T00:00:00 for the ISO8601 strings "1234", "1234-01" and "1234-01-01", you have a problem. Eugene
Re: Standalone Times?
Ben Bennett <[EMAIL PROTECTED]> schrieb/wrote: > There is a related question about what I should _really_ be returning > for the reduced formats. For example, the format matches a year, > right now I return Jan 1st of the year, or YY gives a century, so if > given 20 I return Jan 1st, 2000. Does anyome have a suggestion for a > better return value? Maybe we should have DateTime::Partial that can: . have a precision (like century, year, ISO week, etc.) . be in a reduced format. You could have a method that sets a "default date", i.e. fills the missig fields by looking at a reference date (with different modes). When used as a DateTime object, it just returns the lowest possible value (with a special handling of the year), e.g. a DT::P object with the value "2003-06" (precision: month) behaves like a DT object with the full date "2003-06-01T00:00:00.00 (floating)". Claus -- http://www.faerber.muc.de
Re: Standalone Times?
Bruce Van Allen schreef: > I think the conclusion is _not_ to consider something like 2003-06 as > a span. Agreed. > From a string in the form MM, the DT::F::ISO8601 parser > should return a DT object identical to the DateTime object > instantiated from > $dt = DateTime->new( > year => 2003, > month => 6. > ); No. Let me show you a couple of ISO8601 time intervals, and my interpretation of them: Tomorrow, I have a meeting on "2003-06-22T15/17". I would expect this meeting to start at 15:00:00, and to end at 17:00:00. That is, both start and end times are rounded down. This year, the Tour de France is "2003-07-05/2003-07-27". Cyclist shouldn't expect to go shopping in Paris on the 27th, as they will be busy until late that day (besides, it's a Sunday and the shops will be closed). The best interpretation of that end date is something like 2003-07-27T23:59:59 or 2003-07-28T00:00:00. That is, end date is rounded up (and the start date is rounded down). Julius Ceasar lived "-0099/-0043". The starting date should here be interpreted as "somewhere in 100BC, and the end date should be interpreted as "the ides of March 44BC". Setting both to Jan 1st would be simply wrong. Eugene
Re: Standalone Times?
On Sat, 21 Jun 2003, Joshua Hoblitt wrote: > > It is not clear to me what a value like 2003-06 would mean. Is it "a > > timepoint somewhere in June 2003" (an imprecise datetime), or is it "all > > timepoints in June 2003" (a datetime span)? > > This is why I feel the need for time only objects or at least time only > math objects. Forcing a date to be attached is like adding zero's past > your known precision. Here's the thing. Yes, the object would contain more precision than the original data, _but_ presumably if you are only exchanging "year and month" data, then you will only look at the year and month of the returned object. It's really hard for me to think of a case where you would not know the expected precision in advance. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
