Re: [mplspm]: Picking up the ball

2003-01-09 Thread Dave Rolsky
On Thu, 9 Jan 2003, Chris Josephes wrote: 2. Use the DateTime:: namespace. The [EMAIL PROTECTED] cabal doesn't like it? That's nice. Their buy-in is nice, but lack thereof does not prevent success. And in my experience, when presented with working code that's being used by a bunch of

Re: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Matthew Simon Cavalletto wrote: - DateTime::Base [...] A good candidate for this is the existing Date::ICal code, with a bunch of the Time::Piece convenience methods thrown in for good measure. I'd suggest having an abstract base class one level above the ICal

Re: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Matt Sergeant wrote: What I want to see is a Time::Piece based on Date::Ical (or if that becomes DateTime.pm then fine). I've wanted that since I read the Pod for Date::Ical and realised (like David and Dave have) that it's not just for the ICal format - it's actually a

Re: [mplspm]: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, dLux wrote: I have checked the Date::ICal module, which addressed most of the issues I have faced in the development of Class::Date. Although it does not solve all of this, the module implementation is quite good, ideal for a DateTime base class. I think it certainly

Re: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Matt Sergeant wrote: Don't throw out the baby with the bathwater. There's some good things going for Time::Piece right now: 1. It has a *lot* of users. 2. It has quite a bit of good and mostly reusable code. 3. It's the API blessed/designed by Larry Wall (that may or

Re: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, John Peacock wrote: 1. Stop herding cats. If existing module authors don't want to play, then screw them. One word for you: wrappers. I want to call to your attention the methodology pursued by Tels when he rewrote the Math::BigInt/BigFloat core modules. He

Re: [mplspm]: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, dLux wrote: I disagree with this, because handling these things are not object-dependent, but context-dependent. I need to write a function, which handles dates in one way, but I don't want to force users of the module work dates like this. When I have a function, which

Re: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Rich Bowen wrote: [ CC'd to the Mpls Perl Monger list, Matt Sergeant, and David Wheeler, all of whom have expressed some interest in the topic. I'd suggest that further discussion be solely on the [EMAIL PROTECTED] list, however. ] Thanks, Dave, for doing this. This

Re: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Jean Forget wrote: There *is* a difference between Date:: and Time:: namespaces. Date:: modules do not consider durations less than one day. I did not choose at random between Date:: and Time:: for my module, neither did Rich Bowen (Discordian), Abigail (Maya), Leo

Re: [mplspm]: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Stephen R. Wilcoxon wrote: On Thu 2003/01/09 16:04:04 CST, Dave Rolsky [EMAIL PROTECTED] writes: -- Provides simple date parsing ala Time::Piece-strptime. Maybe throw in the functionality provided by Date::Parse? Maybe make this a separate module. Doesn't matter

Re: [mplspm]: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Ken Williams wrote: Yeah, the base module should accept several different non-ambiguous canonical formats such as the ones used in RFCs, and things like -MM-DD HH:MM:SS. A supplementary module could handle fuzzy stuff like 3 days ago and a month from tomorrow. Just

Re: [mplspm]: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, David Wheeler wrote: On Friday, January 10, 2003, at 01:17 AM, dLux wrote: - To make it supported by the whole perl community, inclucing module developers. For example, I want to pass a date object to the DBI bind_param method without the need of converting it to

Re: [mplspm]: Picking up the ball

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, David Wheeler wrote: The problem with that is that then the particular $sth would have to have the necessary column bound explicitly: $sth-bind_param($param_num, $bind_value, { type = DATE_TIME }); While that'd do-able, it's annoying. I'd rather

A quick note on licensing

2003-01-10 Thread Dave Rolsky
I'm going to make a dictatorial declaration for this project. All code used in the project _must_ be licensed under the same terms as Perl itself. No arguing, no weird licenses, no this software is free, I don't care what you do with it. K? Good. Now, a problem. The following modules need

Base object API/semantics

2003-01-10 Thread Dave Rolsky
So I'm starting to work on turning Date::ICal into DateTime.pm. The first step was a global search and replace. That part went well, and I was very proud of myself. I felt like a super-hacker ;) Then I started added some of the simple-to-add Time::Piece methods, like day_of_year, hms, ymd, and

Picking up the ball

2003-01-09 Thread Dave Rolsky
[ CC'd to the Mpls Perl Monger list, Matt Sergeant, and David Wheeler, all of whom have expressed some interest in the topic. I'd suggest that further discussion be solely on the [EMAIL PROTECTED] list, however. ] Ok, the state of Perl's date and time modules continues to suck. They all have

RE: Picking up the ball

2003-01-09 Thread Dave Rolsky
On Thu, 9 Jan 2003, Darren Young wrote: I've been using Perl for several years and have always HATED doing anything with date/time information. I've avoided it whenever possible because finding a module that will do function(x), actually works and has up to date documentation is nearly

Re: Base object API/semantics

2003-01-10 Thread Dave Rolsky
On Fri, 10 Jan 2003, Dave Rolsky wrote: There's a couple of thoughts I wanted to bounce off of people before I go too much further. Please take a look at the Time::Piece API if you're not familiar with it. Doh, and another thought, unrelated to Time::Piece. What updating methods should

Re: Base object API/semantics

2003-01-10 Thread Dave Rolsky
[ must stop replying to self like the big freak that I am ... ] On Sat, 11 Jan 2003, Dave Rolsky wrote: Right now, this module occasionally warns or carps about bad parameters, and then returns undef. I'm not a big fan of warnings in modules myself. I prefer to either simply return

Re: Base object API/semantics

2003-01-11 Thread Dave Rolsky
On Sat, 11 Jan 2003, David Wheeler wrote: The first option has the advantage of greatly simplifying the internals. Once you calculate the julian day and seconds for an object, it just never changes. The disadvantage is that the API may seem odd to some folks. But we could still provide

Re: Base object API/semantics

2003-01-11 Thread Dave Rolsky
[ Soon the list archives will consistent entirely of me responding to myself ... ] On Sat, 11 Jan 2003, Dave Rolsky wrote: On Sat, 11 Jan 2003, Rich Bowen wrote: On Fri, 10 Jan 2003, Dave Rolsky wrote: Can we simply declare 0-based as the standard for day of week and day of year

Re: Base object API/semantics

2003-01-11 Thread Dave Rolsky
On Sat, 11 Jan 2003, Rich Bowen wrote: On Fri, 10 Jan 2003, Dave Rolsky wrote: Can we simply declare 0-based as the standard for day of week and day of year, and 1-based for day of month, month of year, and week of year. FWIW, that's what Date::ICal already had implemented, I believe

Re: Base object API/semantics

2003-01-11 Thread Dave Rolsky
On Sat, 11 Jan 2003, Matthew Simon Cavalletto wrote: Hmm -- that looks like trouble; month_name() is the written version of month(), but day_name() is the written version of day_of_week() rather than of day(). But days only have names in terms of their position in the week. Unless you call

Re: Which DOW is day #1?

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, David Wheeler wrote: On Sunday, January 12, 2003, at 11:15 AM, John Peacock wrote: A lot of the 0-based vs 1-based arguments should be resolved simply by having our interface design in place. Programmers will be less inclined to have to look up some 0-based array

Re: Discarding some fifteen functions/methods in favour of an enhanced strftime

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote: Ick. That's clearly not as nice as just saying $dt-hour(17). Whether this method is an updater is an entirely different can of worms ;) -dave /*=== House Absolute Consulting www.houseabsolute.com

Re: Base object API/semantics

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, David Wheeler wrote: So keep the base class named DateTime and provide a single implementation class module DateTime::Gregorian, which is the default unless you ask for something else. The advantage of this is we have to work through the interface issues required to

Re: Base object API/semantics

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, dLux wrote: # same as $old_date but day of month is 5 my $new_date = $old_date-clone( day = 5 ); I used this in Class::Date, because of the object-semantics of perl: If an object is referenced from more than one place, then it silently changes all date

Re: Base object API/semantics

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, David Wheeler wrote: John and I liked the former option, though you expressed your opposition to it yesterday. The advantage is that the interface is exactly the same regardless of calendaring system, and we deal with the issues of allowing DateTime to return different

Re: Base object API/semantics

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, Nick Tonkin wrote: Reality is that while a good interface will go a long way towards that goal, there will be a lot of users of the objects that will expect zero-indexed values for a lot of fields for a variety of reasons. And if you want the module to be really useful

Re: Base object API/semantics

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, David Wheeler wrote: On Sunday, January 12, 2003, at 02:33 PM, Dave Rolsky wrote: I think throwing an object is better. I don't really like parsing error messages to determine what error is happened. Just think about internationalization. I think we've agreed

Re: Date::ICal's pseudo-mjd versus real MJD - Rich?

2003-01-12 Thread Dave Rolsky
On Sun, 12 Jan 2003, Yitzchak Scott-Thoennes wrote: Date::ICal uses what Calendrical Calculations uses (that they call Rata Die, fixed date). They are days on or after Jan 1 of year 1 (Gregorian). This different from MJD. I'd like to see Date::ICal switch to using rd to describe them

Re: DateTime Namespace

2003-01-13 Thread Dave Rolsky
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote: # Our core calendar DateTime::Gregorian-- Our primary, modern calendar DateTime::Gregorian::Language -- Internationalization DateTime::Gregorian::RichParser - Based on Date::Manip et al. Except as you point out,

Re: Static objects with dynamic wrappers?

2003-01-13 Thread Dave Rolsky
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote: I was originally unenthusiastic about static date-time objects, but then I realized that it'd be reasonably straightforward to build a variable wrapper object, which could then be used to hold a series of static objects: Ack, too much

Re: Picking up the ball

2003-01-13 Thread Dave Rolsky
On Mon, 13 Jan 2003, Rich Bowen wrote: It's an interesting point in this case, with this being one of the very few calendars that changes how time is handled. However, since the purpose of the module in question is conversion between Gregorian and French Revolutionary, I would expect that it

Re: Parser Interface (Was Re: Picking up the ball)

2003-01-13 Thread Dave Rolsky
On Mon, 13 Jan 2003, Matthew Simon Cavalletto wrote: What's the benefit of making this distinction between core and other formats? Because core parsing would be available simply by doing: use DateTime; That's about it. Why not define a parser interface and include the basic formats as

Re: Internals (Re: Date::ICal's pseudo-mjd)

2003-01-13 Thread Dave Rolsky
On Mon, 13 Jan 2003, Rich Bowen wrote: We had discussed, at some length, over on Reefknot, about making these things storable, and that's an ongoing consideration. Putting an object in the object is all well and good, as long as there is a simple strinification that we can do, and store in a

Re: [mplspm]: Picking up the ball

2003-01-13 Thread Dave Rolsky
On Mon, 13 Jan 2003, Martijn van Beers wrote: But nothing fancy, just a few formats should be supported in the base class, including epoch time, ICal, and maybe ISO 8601. I wouldn't call epoch arguments parsing, but I would really like it if this wasn't in the base class. Making people go

The first day of the week is ...

2003-01-13 Thread Dave Rolsky
Monday! How exciting. I figured I might as well just pick something, and so I picked Monday. There were a lot of excellent candidates, and Friday's performance was excellent, but overall Monday best exemplified the qualities that I look for in a week-starter. -dave /*===

Re: timezones (was Re: Internals)

2003-01-13 Thread Dave Rolsky
On Mon, 13 Jan 2003, Martijn van Beers wrote: gives: [19700329T02..19701025T03], [19710328T02..19711031T03], [19720326T02..19721030T03] The format of the time strings and the recurrence rules are defined in the iCalendar rfc (2445). This was used

Leap seconds

2003-01-13 Thread Dave Rolsky
We need to handle them. Flavio claims that using floating point seconds makes this easier. I have an idea on how to handle it without that, but I'd like to hear Flavio's idea. And if anyone else has any good ideas or pointers to known implementations (I know libtai64 handles it, for one),

Re: [mplspm]: Picking up the ball

2003-01-13 Thread Dave Rolsky
On Mon, 13 Jan 2003, Martijn van Beers wrote: On Mon, Jan 13, 2003 at 01:58:59PM -0600, Dave Rolsky wrote: I agree that epoch is bad, because it's so limited, but it's a standard that a lot of people are familiar with, so it needs to be supported in the core object. That is exactly why

strftime oddities

2003-01-14 Thread Dave Rolsky
Anyone want to tell me what the %E* modifier is supposed to do for stftime? And do we need it? How about the %O* modifier? Is implementing that important? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/

CVS checkins

2003-01-14 Thread Dave Rolsky
For those who care, CVS checkin diffs are sent to the [EMAIL PROTECTED] list (sign up via sourceforge). For now, I don't want to really discuss anything on that list, because the project hasn't really gotten to the point where only a core group of developers should discuss development issues.

Re: Parsing/Formatting API

2003-01-14 Thread Dave Rolsky
On Tue, 14 Jan 2003, Jonathan Scott Duff wrote: I was thinking that a sort of DBI/DBD dichotomy could be applied to DateTimes but along multiple dimensions. Something like this: my $dt = DateTime( parser = DateTime::Parser::MySQL, formatter =

Re: Copyright on algorithms in FAQ (fwd)

2003-01-15 Thread Dave Rolsky
Just as an FYI for all datetime implementors. -- Forwarded message -- Date: 15 Jan 2003 21:56:36 +0100 From: Claus Tondering [EMAIL PROTECTED] To: Dave Rolsky [EMAIL PROTECTED] Subject: Re: Copyright on algorithms in FAQ Hi Dave, You wrote: So we need to know if you're

Re: Calendrical Calculations and licensing

2003-01-15 Thread Dave Rolsky
On Wed, 15 Jan 2003, srl wrote: Rich Bowen emailed them at one point and got an agreement from them that he could implement the algorithms and release the code freely, as long as he let them publish the code in the next version of the book. Last I heard, he was confirming that understanding

Re: Calendrical Calculations and licensing

2003-01-15 Thread Dave Rolsky
On Wed, 15 Jan 2003, Jonathan Scott Duff wrote: I agree, but you forgot step 0: Ask the authors if they'd be willing to release the code under an open source license. It doesn't hurt to ask and if they refuse, then we just continue ignoring the book for implementation advice. I did mention

Re: Parsing/Formatting API

2003-01-15 Thread Dave Rolsky
On Thu, 16 Jan 2003, Ilmari Karonen wrote: module ends up being loaded once per child process. See http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modules_at_Server_Startup for an explanation of why this is important. This doesn't necessarily rule out the -new(

Re: timezones

2003-01-15 Thread Dave Rolsky
On Tue, 14 Jan 2003, Martijn van Beers wrote: Actually, I recently discovered that Date::ICal _does_ support this. if you do $date-ical (localtime = 1) it prints the time adjusted for the local timezone. Floating time *still* has a timezone. It is just variable. But, since your computer can

Re: Parsing/Formatting API

2003-01-16 Thread Dave Rolsky
On Thu, 16 Jan 2003, Nick Tonkin wrote: Umm, improper grammar caused by hasty response caused by a teensy-weensy overdose of hubris? Everyone is in awe of your commitment and energy, Dave ... sometimes you're becoming a bit short with folks, though ... Sorry. I get frustrated when people

Re: Parsing/Formatting API

2003-01-16 Thread Dave Rolsky
On Thu, 16 Jan 2003, Jean Forget wrote: I discovered about %E* and %O* in AIX's date(1) manpage. Nothing about that in Linux's date manpage. The basic specifiers are pretty much consistently defined, but not so for %E* and %O*. And maybe I inadvertently swapped %EY and %OY about Roman

Re: Parsing/Formatting API

2003-01-16 Thread Dave Rolsky
On Thu, 16 Jan 2003, Jonathan Scott Duff wrote: Alternate reality: use DateTime ( Defaults = { parser = DateTime::Parser::Mysql, parserargs = ... }); my $dt = DateTime::parse($mysql_dt_string); or DateTime::parserargs(...); my

Re: New edition of Calendrical Calculations (fwd)

2003-01-16 Thread Dave Rolsky
On Thu, 16 Jan 2003, Rich Bowen wrote: OK, folks, here's a heads up on the issue of license for the Calendrical Calculation code. The commercial statement below is not encouraging, but I'm sending him the licenses, and hoping for the best. If someone wants to step in and give me good

Re: New edition of Calendrical Calculations (fwd)

2003-01-16 Thread Dave Rolsky
On Thu, 16 Jan 2003, Rich Bowen wrote: All points noted and agreed. However, it still makes sense to ask nicely. I have no interest in making enemies of these gentlemen if it is not necessary. I agree. I'm glad _you're_ handling this, not me. I might have gone apeshit on them after

The week (or so) in review

2003-01-16 Thread Dave Rolsky
It's kind of weird for me to realize that I posted my picking up the ball message only last Thursday. Here's a quick review of what's been accomplished so far: - 318 messages to the list! That's 45% of the total list traffic for all time (since May, 2001 or so). Scary but good, as it shows

One more thing about parsers/formatters

2003-01-16 Thread Dave Rolsky
I just realized, as I'm about to start moving the ICal code in the DateTime.pm core to a separate module, that parsers and formatters should be used to deal with durations (ICal has a duration format as well as a datetime format) and possible more complex things, as needed for the format at hand.

Re: Parser/Backend API proposals

2003-01-17 Thread Dave Rolsky
On Thu, 16 Jan 2003, John Peacock wrote: I've been thinking about the API for parsers and storage methods and I have a different suggestion than what has been discussed before. The current model seems to assume that there is a single DateTime object type, regardless of backend storage

CVS activity

2003-01-17 Thread Dave Rolsky
Not that most people can see it with anonymous and web CVS down on SF, but there's been some activity lately. First, I checked in the first stab at DateTime::Formats::ICal, as well as removing all the ICal stuff from the DateTime.pm tests and core code. Second, I added a new top-level module

Anon web CVS is back

2003-01-17 Thread Dave Rolsky
It looks like its back. For how long, who knows? ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/

Re: New edition of Calendrical Calculations (fwd)

2003-01-17 Thread Dave Rolsky
On Fri, 17 Jan 2003, Adam Turoff wrote: On Thu, Jan 16, 2003 at 03:40:57PM -0600, Dave Rolsky wrote: - Point out that at least some portion of this code is _already_ Free Software. See http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/lisp/calendar/ If this is the case, then why

Re: Parser/Backend API proposals

2003-01-17 Thread Dave Rolsky
On Fri, 17 Jan 2003, John Peacock wrote: my $formatter = DateTime::Formats::ISO8601-new ( class = 'DateTime::Implementation::TAI64' ); my $dt = $formatter-parse( ... ); That's OK, but too verbose for the average user, IMHO. It also leaps too deeply into the API

Re: Tests failing

2003-01-19 Thread Dave Rolsky
On Sun, 19 Jan 2003, Rich Bowen wrote: I presume this is actually intentional: t/03componentsok 19/44Can't locate object method ical via package DateTime at t/03components.t line 36. If so, could you please remove the tests that require this method, so that we can have a passing test

Re: Parsing/Formatting API

2003-01-19 Thread Dave Rolsky
On Sun, 19 Jan 2003, John Siracusa wrote: That's a nice idea, but people may want to use these modules without using DBI And so they can. What's stopping them? Nothing. I'm just saying that the API needs to work both for standalone use and for use by the DBI modules. and I have no

Re: Parsing/Formatting API

2003-01-19 Thread Dave Rolsky
On Sun, 19 Jan 2003, John Siracusa wrote: Okay, but my point was that standalone use of db-specific date formatting and parsing (i.e. in the absence of a $dbh) will be very rare (assuming we do get it hooked into DBI as proposed). So while it should still certainly be possible, don't spend

Re: Parsing/Formatting API

2003-01-19 Thread Dave Rolsky
On Sun, 19 Jan 2003, Nick Tonkin wrote: I'm with John on this. I think the earlier this is designed in, the better. And I know Tim, a friend and former employee, would agree. That's cool. Seeing as this isn't a super-important feature for me, and my plate is reasonably well packed, I'd be

Re: Which DOW is day #1?

2003-01-24 Thread Dave Rolsky
On Fri, 24 Jan 2003, Peter J. Acklam wrote: I believe this thread proves that what is considered the first day of the week must be customizable. If it isn't, then someone (perhaps not someone on this mailing list, but someone) will be dissatisfied and consider the DateTime modules useless

Re: Which DOW is day #1?

2003-01-24 Thread Dave Rolsky
On Fri, 24 Jan 2003, Clayton L. Scott wrote: So if I want to use Sunday as the first day of the week every will method I use will have sunday in it? What if for some business reason I decide that it's easier to do my calculations if Wednesday is the first day of the week? How about: use

Re: Set/Get methods

2003-01-24 Thread Dave Rolsky
On Fri, 24 Jan 2003, Bruce Van Allen wrote: Some of the discussion was about whether or not DateTime objects should be updatable at all. It appeared to me that consensus formed to have objects static, and updating would be done via cloning: $dt = DateTime-new( year = 2001, month = 5, day

Help me understand time zones

2003-01-24 Thread Dave Rolsky
So I'm hacking away at time zone code and getting darn close to producing something usable, dare I even say elegant? We'll see on both counts, I suppose ;) Anyway, I've been working with the raw Olson DB the last couple days, and I've produced a parser that can read its rules, zones, links and

Working time zone code!

2003-01-27 Thread Dave Rolsky
I just checked in a lot of new/changed code under modules/DateTime-TimeZone. This code actually seems to work, and provides access to the complete Olson historical data, plus ongoing time zone changes in the future. I'd realy appreciate some code review on this, even though it's still a bit

Re: Grand Unified Theory of Date/Time modules

2003-01-27 Thread Dave Rolsky
On Tue, 28 Jan 2003, Peter J. Acklam wrote: [...] the fact that an ISO date can be expressed 6 different ways, which makes ISO less attractive to me. I don't see why this is relevant. A date may be represented in many more than six ways, but as long as one picks one format and everyone

Re: Grand Unified Theory of Date/Time modules

2003-01-27 Thread Dave Rolsky
On Tue, 28 Jan 2003, Eugene van der Pijll wrote: On the other hand, I would like to be able to specify a date with a precision of less than a day. For example, the date 1815, or july 1974. But I'll write my own module around DateTime that can handle these dates, if necessary. You'll probably

Re: Grand Unified Theory of Date/Time modules

2003-01-27 Thread Dave Rolsky
On Mon, 27 Jan 2003, John Peacock wrote: Hence, it would seem to me to make the most sense to store the basic DateTime object as an array of (possibly undefined) periods: years, months, days, hours, minutes, seconds, etc. By doing it this way, instead of some sort of days since some epoch,

Re: Grand Unified Theory of Date/Time modules

2003-01-27 Thread Dave Rolsky
On Tue, 28 Jan 2003, Rick Measham wrote: My argument against this is due to the multitude of time representations that the module should be able to work with - without heaps of calculations. Storing 'Months' is useful for Gregorian calendars, but is annoyingly useless for decimal calendars.

Re: Grand Unified Theory of Date/Time modules

2003-01-28 Thread Dave Rolsky
On Tue, 28 Jan 2003, John Peacock wrote: Tell you what; I'll write an implementation of my way (probably in XS) and we'll compare. I think you're mistaken; your storage methods requires conversion for all nontrivial operations (e.g. $dt-year), whereas mine only needs a conversion when

Re: Grand Unified Theory of Date/Time modules

2003-01-28 Thread Dave Rolsky
On Tue, 28 Jan 2003, Peter J. Acklam wrote: I searched the archives and read a whole lot of postings, but didn't find anything about what I wrote, so that's why I posted it. I wanted to join this project and contribute something, but first I wanted to understand the reason behind some of

Re: Grand Unified Theory of Date/Time modules

2003-01-28 Thread Dave Rolsky
On Tue, 28 Jan 2003, John Peacock wrote: Dave Rolsky wrote: Well, an XS implementation is quite likely to beat pure Perl, even if you used RD days as well. Don't tell anyone, but my first pass will be pure Perl, since I am still pretty much an XS newbie... Hehe, that's fine. My guess

Re: Grand Unified Theory of Date/Time modules

2003-01-28 Thread Dave Rolsky
On Tue, 28 Jan 2003, John Peacock wrote: Hehe, that's fine. My guess is that this is probably a much easier way to write an XS module, since all you'll have to do is re-implement the same logic in C, which leaves you free to _only_ think about all the low-level C crap you have to deal

Re: Changing time zones?

2003-01-31 Thread Dave Rolsky
On Fri, 31 Jan 2003, John Peacock wrote: Let me think out loud now. If we are always storing time _and_ TZ, then it certainly make more sense to me to use UTC to store the time. How's this for a good example (pseudo-code): my $t1 = new DateTime::Simple (2002-12-30T08:00:00, TZ =

Local times and time zones

2003-02-01 Thread Dave Rolsky
In fixing the brokenness of the time zone code, I've come across what appears to be an insoluble problem. We want to allow people to create a DateTime object based on their _local_ time. Internally, we want to have UTC time available, so we need to know the offset for a given local time. This

datetime.perl.org

2003-02-01 Thread Dave Rolsky
This hostname now exists and I can put stuff on it, including dynamic content (with mod_perl and preferable, Mason). Submissions for content are welcome. Some things I'd like to put up there: - info about existing modules - developer docs for DateTime project - useful links (Olson DB,

Floating time zone = non-floating

2003-02-02 Thread Dave Rolsky
If I have a datetime object with a floating time zone and then I set the time zone to some non-floating zone, I shouldn't change the local time, right? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/

Re: Floating time zone = non-floating

2003-02-02 Thread Dave Rolsky
On Sun, 2 Feb 2003, Dave Rolsky wrote: If I have a datetime object with a floating time zone and then I set the time zone to some non-floating zone, I shouldn't change the local time, right? And how about non-floating = floating? Same thing, no adjustment, right? -dave

Re: Grand Unified Theory of Date/Time modules

2003-02-03 Thread Dave Rolsky
On Mon, 3 Feb 2003 [EMAIL PROTECTED] wrote: There is something else to consider. What does a timestamp of May 5, 1776, 4:16:23 PM actually _mean_? For May 5, 1976, 4:16:23 PM, it's clear which point in time we mean when we have the timezone. But for dates 200 years ago, it isn't so clear.

Re: Parameters outside proper boundaries

2003-02-04 Thread Dave Rolsky
On Wed, 5 Feb 2003, Rick Measham wrote: POD The behavior of this module when given parameters outside proper POD boundaries (like a minute parameter of 72) is not defined, though POD future versions may be die. I'd prefer the behavior of: my $dt = DateTime-new( hour = 7, minute = 75); to

Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00

2003-02-04 Thread Dave Rolsky
On Tue, 4 Feb 2003, John Peacock wrote: Please try them out and let me know what you think, what bugs you find, etc. I don't like the fact that I have to install DateTime::TimeZone blind (i.e. no testing) before I can test/install DateTime. I would much rather that some way be found to

Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00

2003-02-04 Thread Dave Rolsky
On Wed, 5 Feb 2003, Rick Measham wrote: Please try them out and let me know what you think, what bugs you find, etc. A 'Teehee' from the docs: $dow = $dt-day_of_week;# 1-7 (Monday is 1) ... $day_name = $dt-day_name # Sunday, Monday If Monday=1 and Sunday=7 then

Re: DateTime::TimeZone 0.01_00

2003-02-05 Thread Dave Rolsky
On Wed, 5 Feb 2003, Yitzchak Scott-Thoennes wrote: No, Test::More is loaded by the use Test::More line. This is equivalent to: BEGIN { require Test::More; Test::More-import; } But use_ok doesn't work right since the 'plan tests = 1' hasn't been done yet. There seems to be a bug in

Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00

2003-02-05 Thread Dave Rolsky
On Wed, 5 Feb 2003, John Peacock wrote: No, it's clear that the modules are deeply intertwined. My primary concern is that it is currently impossible to install both on a fresh machine without skipping the tests on one of the two (at least to begin with). In my mind, DateTime is the parent

Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00

2003-02-05 Thread Dave Rolsky
On Thu, 6 Feb 2003, Rick Measham wrote: I'd argue against this (and possibly the code in TimeZone.pm for handling a time zone of local). I live in Australia and my timezone is +1100. But I host in the US someplace where the machine has a timezone of -0600. I'd prefer to be able to set my

article reviewers wanted

2003-02-05 Thread Dave Rolsky
I could use a couple volunteers to review an article I'm writing about date time modules for perl.com. The first few volunteers select will receive my gratitude, a brand new email attachment, and that's about it. -dave /*=== House Absolute Consulting www.houseabsolute.com

Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00

2003-02-06 Thread Dave Rolsky
On Wed, 5 Feb 2003, Yitzchak Scott-Thoennes wrote: Now that's a PITA! It depends on Net::FTP _and_ Archive::Zip (the TZ data is in a zip file). Too much work for now at least. Take a look at e.g. Math::Pari's Makefile.PL if you want to see an example of FTP. I've used Net::FTP many

ANNOUNCE: DateTime::TimeZone 0.01_01

2003-02-06 Thread Dave Rolsky
Just a few quick fixes: - Fixed the problem running the 01load.t test seen with some versions of Test::More. Reported by John Peacock. - The generated modules no longer contain any POD, since that really doesn't serve any useful purpose, and just wastes disk space. -dave

Re: Moving the INTERNAL timezone

2003-02-06 Thread Dave Rolsky
On Fri, 7 Feb 2003, Rick Measham wrote: A while back Dave asked us about timezones and should setting a timezone move the internal representation or the external. We all agreed on the external. Mainly because we couldn't think of a use for internal. Well, for the first time ever, I'm using

Re: DateTime, the year 0, and ISO8601

2003-02-12 Thread Dave Rolsky
On Wed, 12 Feb 2003, Peter J. Acklam wrote: On your other point: I think it would be nice if DateTime::new would accept years like '1974AD', '44BC, '2003CE' and '753BCE'. But most people would say the year -753 meant 753 BC, so I would keep that definition. This implies that someone

Re: DateTime, the year 0, and ISO8601

2003-02-12 Thread Dave Rolsky
On Wed, 12 Feb 2003, Eugene van der Pijll wrote: By the way, how do you know what the standard requires if you haven't read it? ;-) I trust you completely. Unfortunately, ISO 8601 isn't avaliable online, and none of the summaries I've read contain the expanded format. You can get the

API for Format modules

2003-02-12 Thread Dave Rolsky
On Thu, 13 Feb 2003, Rick Measham wrote: On 13/2/03 9:05 am, Dave Rolsky at [EMAIL PROTECTED] spake thus: This is why there will be a DateTime::Format::ISO8601 module for parsing ISO formats ;) Dave, having worked with the DateTime::Format::iCal module, and with its innards, I wonder

Re: offset_as_seconds fix introduced new bug

2003-02-13 Thread Dave Rolsky
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote: b. pass the $p{name} to OffsetOnly-new() instead of $offset (and force $offest to be calculated twice) That's what I'll do. But it won't force offset to be calculated twice, actually. -dave /*=== House Absolute Consulting

Re: offset_as_string, a patch

2003-02-13 Thread Dave Rolsky
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote: There is a minor bug in offset_as_string, when calculating the offset for negative timezones. If you pass in the timezone -05:00, offset_as_string returns -19:00 this is because, according to Perl, -5%24 == 19. the solution is to change $hours

Re: support timezone 'Z', patch

2003-02-13 Thread Dave Rolsky
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote: A minor feature enhancement that would be great is support for the standard timezone 'Z' which is an alias for UTC. It is frequently used both in the ICal spec, and in the W3CDTF profile[1] which is the standard time format for RSS. That makes

  1   2   3   4   5   6   7   8   9   10   >