Re: milli/micro seconds
On Wed, 11 Jun 2003, Dave Rolsky wrote: On Tue, 10 Jun 2003, Joshua Hoblitt wrote: I've started on milliseconds and microseconds support (DT::Duration to start with). I hope nobody else has already done this. Um, don't we already have this with nanoseconds? What are you thinking of adding? Adding millisecond and microsecond constructor parameters to DT and DT::Duration that just convert to be to stored as nanoseconds. Probably add delta_millisecond and delta_microsecond methods to DT::Duration. This is listed in the TODO. -J --
Re: It could be worse ;)
http://www.onjava.com/pub/a/onjava/2003/06/05/java_calendar.html See, it could be worse ;) OMG - they paid people to come up with that? To quote SNL: Who are the ad wizards that came up with that one? -J --
Re: Converting to DT
On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote: On Tue, 10 Jun 2003, Ben Bennett wrote: However, I have no idea how fast this is and how much memory it consumes. I will try to release what I have tonight (when I hope to have it in a more usable state). I played with P::RecDescent for Mason, and it is slow and a memory hog. That's no dis to Damian, cause it's a great tool, but in most cases a custom regex-based parser is way faster. I agree. And I'll repeat my (carefully worded) statement that A single regex could handle all formats that follow the ISO 8601 general left-to-right decreasing resolution style, with assorted optional punctuation, plus optional appended TZ. I'm assuming here that a DateTime::Format::Common module should only support four digit years. If you need two digit years then use a specific date parser module. Similarly I'd prefer it to not handle named months (as per ISO 8601) but if it does, then only the English three character abbreviations. Again, if you need more, use a specific date parser module. The DateTime::Format::Common should be *small and fast*. So no Parse::RecDescent, and no fancy features. Those that want an all-singing-all-dancing-guess-your-weight date parser should work on a new, separate, module that can be loaded with all the smarts you want. Tim.
Re: DateTime::Duration is_positive bug?
Dave Rolsky wrote:
On Wed, 11 Jun 2003 [EMAIL PROTECTED] wrote:
...
sub is_positive { $_[0]-{sign} == 1 ? 1 : 0 }
which makes a zero-duration be not positive,
because sign is zero.
That was an intentional change. Zero isn't positive, is it?
That's right.
I asked it because DT::Format::ICal tests
are failing, because a zero-duration is
being tested with is_positive.
BTW, do we need DT::Duration-is_zero ?
- Flavio S. Glock
Re: Converting to DT
On Wed, 11 Jun 2003, Tim Bunce wrote: And I'll repeat my (carefully worded) statement that A single regex could handle all formats that follow the ISO 8601 general left-to-right decreasing resolution style, with assorted optional punctuation, plus optional appended TZ. In fact, this'd be pretty much what Date::Parse does ;) I'm assuming here that a DateTime::Format::Common module should only support four digit years. If you need two digit years then use a specific date parser module. Ben, I'd recommend taking a look at this for writing DT::F::Common. A module that parsed Date::Manip stuff would be called DT::F::Complex or something like that. The Date::Parse stuff is much more useful for most people though. In fact, DT::F::Common could probably just wrap around Date::Parse, or alternately, just rip the guts out and stuff it in a new module. The DateTime::Format::Common should be *small and fast*. Just like Date::Parse ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Converting to DT
On Wed, 11 Jun 2003, Tim Bunce wrote: And I'll repeat my (carefully worded) statement that A single regex could handle all formats that follow the ISO 8601 general left-to-right decreasing resolution style, with assorted optional punctuation, plus optional appended TZ. In fact, this'd be pretty much what Date::Parse does ;) Parse::Date is limited to dates that Time::Local can handle. (It also uses Time::Zone for named timezones.) Only the str2time function uses T::L. And that's only so it can return an epoch. The strptime function, which does all the work, doesn't need it. I'd say rip the guts out and stuff it in a new module focused on working with DateTime. Drop anything that gets in the way (like Time::Local), two digit years, and perhaps named timezones. Supporting Olson time zones should be too hard, since it's just a string match [a-zA-Z0-9/] at the beginning or end. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: milli/micro seconds
At 9:29 AM -1000 11/6/03, Joshua Hoblitt wrote: I'm willing to concede that DT::Duration can be left alone but I really think that millisecond and microsecond support would be useful for DT. In fact I think it would be consistent with the rest of the API as you don't have to specify a year as 365 days either. While I know that a millisecond needs to be multiplied by 10**6 to convert it nanoseconds I don't think that qualifies as common knowledge. DISCLAIMER The following is tacked on as a reply to Joshua's post, but that it just to give it context. This in no way is a personal attack on him or anyone else who has talked about sub-second accessors and constructors, but rather on the whole idea in general. /DISCLAIMER Datetimers, I can understand why we look like we need all this stuff for milli-, micro- and nano-seconds, but it is exactly what I was scared of when we were talking about sub-second support. Nano-, Milli- and Micro- seconds are not different things like hours an minutes are, they're just fractional seconds. We really should have just left it as floating seconds, or as fractional seconds rather than settling on some arbitrary precision like nanoseconds. If we allow a constructor for nano-, micro- and milli- then maybe we should allow one for decaminutes? The same with accessors. They're just descriptions of the same thing: fractions. A millisecond is 1/1000 seconds, a decaminute is 10/1 minutes. You can represent time with accessors like: -hour:-minute:-second, but accessors like micro- and milli- are ambiguous. They look like the other accessors so can you just 'whack them on'? $dt-hour . ':' . $ct-minute . ':' . $st-second . '.' . $dt-millisecond . $dt-microsecond . $dt-nanosecond I doubt it. You'll have to pick your precision and only use that. We really should have just left it as -second and -fractional_second and probably -floating_second($precision) (returning floating, not fractional seconds). We especially don't need them in the constructor. It's confusing now: $dt = DateTime-new(%date, second=12, nanosecond=345) Is that 12.345 seconds? Nup. It's 12.00345 (I think). $dt = DateTime-new(%date, second=12, fractional_second=345) Is that 12.345 seconds? Nup. It's 357 seconds! Imagine extra constructors, it feels good at first: $dt = DateTime-new( year=2003, month=6, day=12, hour=7, minute=22, second=12, millisecond=345, microsecond=678, nanosecond=901 ); However, the accessors don't 'behave' themselves: $dt-year== 2003 .. yup $dt-month == 6.. yup $dt-day == 12 .. yup $dt-hour== 7.. yup $dt-minute == 22 .. yup $dt-second == 12 .. yup $dt-millisecond == 347 .. oops $dt-microsecond == 345678 .. hang on, where did all that come from, we constructed it with just '678' $dt-nanosecond == 345678901 .. same here, it used to be just '901' Of course you could have extra accessors for -just_nanoseconods (returns 901), -just_microseconds and -just_milliseconds, but it's all a little silly. Can't we can the nanosecond and just talk about seconds (and fractional seconds)? Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: Converting to DT
At 4:28 PM -0500 11/6/03, Dave Rolsky wrote: 5.00503 is the goal for all DateTime modules, and anyone writing a DT module should have a damn good reason for _not_ supporting it. qr// does indeed work with 5.00503. Since when? This is perl, version 5.005_03 built for i386-freebsd I went through seven stage of hell trying to get it installed. IIRC I had to hack Time::Local. Can't remember though, all I remember is that it wasn't just a case of perl Makefile.PL, make, make test, make install. Does anyone have a legacy system they can try to install on? Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: milli/micro seconds
At 4:36 PM -0500 11/6/03, Dave Rolsky wrote: No, if anything, we'll can the fractional_second constructor parameter. Nanoseconds are here to stay, because I don't want to add bigfloat to the mix, and I want us to be accurate. Dave, can you explain to me again why we need nanosecond (an arbitraty fraction) rather than just using fractional seconds? (not floating, fractional) What we're talking about *is* fractional seconds, why not just call it that? There's no imprecision that doesn't already exist in your computer. If your computer can only handle floats down to 6 decimal places, then you're screwed with any other math anyway! Even if it handles it way down to 100 places, as soon as you ask for 'half the googliseconds' you loose precision. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: Converting to DT
On Thu, 12 Jun 2003, Rick Measham wrote: At 4:28 PM -0500 11/6/03, Dave Rolsky wrote: 5.00503 is the goal for all DateTime modules, and anyone writing a DT module should have a damn good reason for _not_ supporting it. qr// does indeed work with 5.00503. Since when? This is perl, version 5.005_03 built for i386-freebsd I went through seven stage of hell trying to get it installed. IIRC I had to hack Time::Local. Can't remember though, all I remember is that it wasn't just a case of perl Makefile.PL, make, make test, make install. Does anyone have a legacy system they can try to install on? Yeah, me. DT.pm uses qr// internally and I always run tests on 5.00503, 5.6.1, and 5.8.0 before each release. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Time
At 5:04 PM +1000 6/6/03, Rick Measham wrote: The attached module is a time-only implementation of DateTime. Did this: 1) escape the radar, 2) not interest anyone, 3) handle everything so embarassingly wrong that none of you kind-hearted folks wants to say anything :) Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: DateTime::Time
On Thu, 12 Jun 2003, Rick Measham wrote: At 5:04 PM +1000 6/6/03, Rick Measham wrote: The attached module is a time-only implementation of DateTime. Did this: 1) escape the radar, 2) not interest anyone, 3) handle everything so embarassingly wrong that none of you kind-hearted folks wants to say anything :) I guess I need to understand what it's purpose is. Can you show me some examples of how you'd want to use it? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: Adding custom locales to DateTime::Locale
What exactly is prevent you from just passing an object as the language parameter to the DateTime constructor? DT::Language can't be subclassed from outside the DT::Language tree because of the way the constructor works. My patch makes it so that when -new is called without any arguments an object of that class is returned (instead of using the load mechanism). -J --
Re: Converting to DT
On Thu, 12 Jun 2003, Rick Measham wrote: Does anyone have a legacy system they can try to install on? At 4:59 PM -0500 11/6/03, Dave Rolsky wrote: Yeah, me. DT.pm uses qr// internally and I always run tests on 5.00503, 5.6.1, and 5.8.0 before each release. It wan't a qr//, it might have been a 'our', but I don't think so, there was just some real problem getting it installed. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: milli/micro seconds
On Thu, 12 Jun 2003, Rick Measham wrote: At 4:36 PM -0500 11/6/03, Dave Rolsky wrote: No, if anything, we'll can the fractional_second constructor parameter. Nanoseconds are here to stay, because I don't want to add bigfloat to the mix, and I want us to be accurate. Dave, can you explain to me again why we need nanosecond (an arbitraty fraction) rather than just using fractional seconds? (not floating, fractional) What we're talking about *is* fractional seconds, why not just call it that? There's no imprecision that doesn't already exist in your computer. If your computer can only handle floats down to 6 decimal places, then you're screwed with any other math anyway! Even if it handles it way down to 100 places, as soon as you ask for 'half the googliseconds' you loose precision. Now you're confusing me! Fractional by itself doesn't mean anything, does it? You can't just the numerator without the denominator. In our case, the denominator is 1,000,000,000 and the numerator is the the value of the nanosecond parameter. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: milli/micro seconds
On Wed, 11 Jun 2003, Tim Bunce wrote: On Wed, Jun 11, 2003 at 09:29:31AM -1000, Joshua Hoblitt wrote: While I know that a millisecond needs to be multiplied by 10**6 to convert it nanoseconds I don't think that qualifies as common knowledge. Sounds like a documentation patch is needed :) It wouldn't hurt but I still think this would a convenient feature. The amount of code is minimal. Although I suppose it could be achieved with a wrapper class. -J --
Re: milli/micro seconds
Ok - this thread has certainly caused a lot of controversy. To comment on Rick's comments - I think that Dave made the correct decision to have fixed precision subsecond resolution. I in no way so attempting to insinuate this wasn't the right thing to done. I will _NOT_ submit a patch to add more constructor parameters. Instead... Proposal: A new 2nd tier namespace for wrapper classes. DateTime::Wrap or DateTime::Wrapper DateTime::Wrapper::SubSecond will accept parameters for resolutions from 10 to 10^9 subseconds. With corresponding methods returning these units. Comments? -J --
Re: milli/micro seconds
At 12:19 PM -1000 11/6/03, Joshua Hoblitt wrote: Proposal: A new 2nd tier namespace for wrapper classes. DateTime::Wrap or DateTime::Wrapper DateTime::Wrapper::SubSecond will accept parameters for resolutions from 10 to 10^9 subseconds. With corresponding methods returning these units. Cool idea .. and I'll add DateTime::Wrapper::AllowThingsToOverflow (or something shorter) that allows you to construct with overflowing parameters (like 75 seconds, 124 minutes, 34 hours, 98 days and 16 months) Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: milli/micro seconds
On Wed, 11 Jun 2003, Joshua Hoblitt wrote:
DateTime::Wrapper::SubSecond will accept parameters for resolutions from
10 to 10^9 subseconds. With corresponding methods returning these
units.
This seems like overkill for something which will basically do:
my $nano = $p{micro} * 1000;
Which is why I wanted to put it in the core. This seems to be a
circular argument. :)
The problem with making it a constructor option is that if a user passes
nanosecond _and_ micro/milli parameters, it's confusing. It's bad enough
that fractional_second and nanosecond are overlapping, and in a really
weird way now that I look more closely!
Ugh, the fractional_second parameter must go. The docs for it are all
wrong, and what it's actually doing is _really_ odd.
Anyway, I _really_ don't like having mututally exclusive, but overlapping,
constructor parameters. This makes for hard-to-read docs. Ideally, each
parameter is unique, and falls into the category of required, has
default, or optional.
I said a _wrapper_ was overkill because you could just as easily write
something like:
micro_as_nano { $_[0] * 1000 }
milli_as_nano { $_[0] * 100 }
and then do:
DateTime-new( ..., nanosecond = milli_as_nano(500) )
Isn't that simpler? Is there any need to wrap all the DateTime
constructors? No, obviously not. It's two one-liner exported functions
that are mere syntactic sugar!
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: milli/micro seconds
Ugh, the fractional_second parameter must go. The docs for it are all
wrong, and what it's actually doing is _really_ odd.
Sounds reasonable.
Anyway, I _really_ don't like having mututally exclusive, but overlapping,
constructor parameters. This makes for hard-to-read docs. Ideally, each
parameter is unique, and falls into the category of required, has
default, or optional.
I said a _wrapper_ was overkill because you could just as easily write
something like:
micro_as_nano { $_[0] * 1000 }
milli_as_nano { $_[0] * 100 }
and then do:
DateTime-new( ..., nanosecond = milli_as_nano(500) )
Isn't that simpler? Is there any need to wrap all the DateTime
constructors? No, obviously not. It's two one-liner exported functions
that are mere syntactic sugar!
Ya - too bad there aren't isn't any preprocessor other then source filters. I don't
like writing structural code over and over again.
-J
--
Re: 3 letter timezones (was month name to number)
Any progress on this? I seem to recall that Rick volunteered to do it but I don't see that in the thread. I just started work on it anyways. If Rick already has something we can just use that instead. -J --
Re: 3 letter timezones (was month name to number)
Cool. I want to mention it in the FAQ and I want to use it in the Complex parser... -ben On Wed, Jun 11, 2003 at 03:33:09PM -1000, Joshua Hoblitt wrote: Any progress on this? I seem to recall that Rick volunteered to do it but I don't see that in the thread. I just started work on it anyways. If Rick already has something we can just use that instead. -J --
Re: 3 letter timezones (was month name to number)
On 12/6/03 11:33 AM, Joshua Hoblitt at [EMAIL PROTECTED] spake thus: Any progress on this? I seem to recall that Rick volunteered to do it but I don't see that in the thread. I just started work on it anyways. If Rick already has something we can just use that instead. Strptime contains a list of three-letter timezones, however if you have a look you'll see that it returns 'ambiguous' on any that were ambiguous. I can recreate it with all the information if you want. Cheers! Rick
Re: 3 letter timezones (was month name to number)
Any progress on this? I seem to recall that Rick volunteered to do it but I don't see that in the thread. I just started work on it anyways. If Rick already has something we can just use that instead. Strptime contains a list of three-letter timezones, however if you have a look you'll see that it returns 'ambiguous' on any that were ambiguous. I can recreate it with all the information if you want. I've got something working (basic proof of concept - what do you expect 23mins :) ). I'm writing a couple of quick tests and I post it for comments shortly. -J --
Nanoseconds in the FAQ.
I added a section on nanoseconds: http://www.limey.net/~fiji/perl/faq.html#2.9%3A%20How%20small%20an%20increment%20of%20time%20can%20I%20represent%3F The raw POD is below. I deliberately did not mention fractional_second since Dave suggests that it is going away... If this is not true, please let me know and I will add info on it. -ben =head3 How small an increment of time can I represent? ADateTime can represent nanoseconds. You can create obects with that resolution using the Cnanosecond parameter to Cnew or Cset and there is a corresponding Cnanosecond accessor. For these you give an integer count of the nanoseconds. A millisecond is a thousandth of a second (10^-3 or 0.001). The abbreviation is Ims. A microsecond is a millionth of a second (10^-6 or 0.01). The abbreviation is Ius (or more properly IEmicros). A nanosecond is a billionth (US) of a second (10^-9 or 0.1). The abbreviation is Ins. =for example begin # The ns part is 0.00230 below my $dt_ns = DateTime-new(year = 2003, month = 3, day = 1, hour = 6,minute = 55, second = 23, nanosecond = 230); print ns: , $dt_ns-nanosecond, \n; # Prints: ns: 230\n # Assuming we got microseconds as an argument my $ms = 42; my $dt_ms = DateTime-new(year = 2003, month = 3, day = 1, hour = 6,minute = 55, second = 23, nanosecond = $ms * 1_000_000); print ms: , $dt_ms-nanosecond, \n; # Prints: ms: 4200\n =for example end =for example_testing is($_STDOUT_, ns: 230\nms: 4200\n, Nanoseconds);
Re: Nanoseconds in the FAQ.
On Wednesday, June 11, 2003, at 07:08 PM, Ben Bennett wrote: I added a section on nanoseconds: The raw POD is below. =head3 How small an increment of time can I represent? ADateTime can represent nanoseconds. You can create obects with =for example begin # The ns part is 0.00230 below my $dt_ns = DateTime-new(year = 2003, month = 3, day = 1, hour = 6,minute = 55, second = 23, nanosecond = 230); print ns: , $dt_ns-nanosecond, \n; # Prints: ns: 230\n # Assuming we got microseconds as an argument ^ I think you meant:milli my $ms = 42; my $dt_ms = DateTime-new(year = 2003, month = 3, day = 1, hour = 6,minute = 55, second = 23, nanosecond = $ms * 1_000_000); print ms: , $dt_ms-nanosecond, \n; # Prints: ms: 4200\n ^^ That number is in nanoseconds (42 milliseconds is 42,000,000 nanoseconds); does it make sense to label it 'ms' in the test output? - Bruce __bruce__van_allen__santa_cruz__ca__
namespaces, command and control
While writing some documentation for the DateTime project ( http://datetime.perl.org ) I seem to have brought up the question of namespace control. This is the paragraph in question: -- =head2 Namespace Allocation CDateTime::* namespace is allocated by the C[EMAIL PROTECTED] mailing list. Do not create a new 2nd tier namespace without first seeking approval from the list. Unless specifically noted as Copen most 2nd tier namespaces are not available to 3rd party developers. -- Currently we have modules in the DateTime namespace and more then a dozen 2nd tier namespaces. Is it appropriate for us [the DateTime 'Asylum'] to be presuming some sort of control over the DateTime namespace? Further, is it possible to seek control over a top level namespace? I believe there is some president for this, for example DBI, but the issue does seem somewhat vague. At least nothing of this nature seems to be officially ordained. Any clarification would be appreciated. Cheers, -J --
Re: namespaces, command and control
On Wed, 11 Jun 2003, Joshua Hoblitt wrote: namespace? I believe there is some president for this, for example DBI, He means precedent ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: namespaces, command and control
On Wed, 11 Jun 2003, Dave Rolsky wrote: On Wed, 11 Jun 2003, Joshua Hoblitt wrote: namespace? I believe there is some president for this, for example DBI, He means precedent ;) I blame Aspell. :) -J --
