Re: [Patch] DT::TZ Offsets
Can you change it so that the maximum offset is 24:00:00 and then check it in? There's no official limit on offsets are there? I can envision some small country declaring an offset of greater then 24hours. -J --
Re: [Patch] DT::TZ Offsets
On Fri, 22 Aug 2003, Joshua Hoblitt wrote: Can you change it so that the maximum offset is 24:00:00 and then check it in? There's no official limit on offsets are there? I can envision some small country declaring an offset of greater then 24hours. You can? That doesn't make much sense to me. If it happens, we can change the code ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Subtraction Broken?
Joshua Hoblitt schreef: What you want is to normalize the values of a duration relative to some fixed point in time. I agree this is something that we need to do. Patches are welcome. :) So if I read this correctly the answer is at this time what I'm after is not possible with DateTime directly. But, what I request is something you all desire and hope to have working when someone has the time. I actually wouldn't mind taking a look to see if I could contribute but at this point if: You are getting the _correct_ answer. Let me say that again. You are getting the _correct_ answer. The information is exactly what you asked for. It just not in the units that you want. No, he's getting _a_ correct answer. The information is _not_ what he has asked for. 2003-08-23 minus 1970-08-23 is both equal to 23 years, and to 12053 days, even though 23 years is very much different from 12053 years. The units that you are asking for are of variable length and depend on the context in which they are used. Days also have a variable length. Only DT::Duration's that contain only a 'seconds' component represent time intervals of constant length. The reason why DT::subtract_datetime returns a DT::Duration with days and seconds, is the way DT's are implemented internally: rd_days and rd_seconds. It's easier and faster to just subtract these values. It is not a stub. It should not produce 35. You really don't seem to believe me but the behavior is _correct_. What you are asking for is a DT::Duration relative to DateTime and the infrastructure simply doesn't exist yet. The infrastructure does exist: a DT::Duration can contain years (actually, it contains months; but the conversion months = years is unique), and a DT of say 2 years and 3 months already is relative to DateTime. The only problem is that DT::subtract_datetime doesn't use it. It probably should. (It would be even better if there was an option to calculate the difference in days secs. But the default should probably be to return a difference of months, days, minutes, seconds.) Eugene
Re: Subtraction Broken?
On Sat, 23 Aug 2003, Eugene van der Pijll wrote: The only problem is that DT::subtract_datetime doesn't use it. It probably should. (It would be even better if there was an option to calculate the difference in days secs. But the default should probably be to return a difference of months, days, minutes, seconds.) I think the default should probably be the accurate method, but I do think offering a way to return the other values would be good. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Subtraction Broken?
The only problem is that DT::subtract_datetime doesn't use it. It probably should. (It would be even better if there was an option to calculate the difference in days secs. But the default should probably be to return a difference of months, days, minutes, seconds.) I think the default should probably be the accurate method, but I do think offering a way to return the other values would be good. I'm a bit nervous about building that into DT::Duration. If a resulting vague result is reused for date math someone could blow their foot off an not realize it. -J --
Re: [Patch] DT::TZ Offsets
There's no official limit on offsets are there? I can envision some small country declaring an offset of greater then 24hours. You can? That doesn't make much sense to me. If it happens, we can change the code ;) The universe doesn't always make sense to you? :) I choose 99:59:59 as the offset limit as that's the maximum time value that can be represented by that number of digits. If someone wants to specify an offset of 24 hours I'm willing to assume they know what they're asking. It doesn't cause us any pain as it fits within the format we're already supporting. Of course we could also optionally accept duration objects as offsets specifiers... That actually doesn't sound like a bad idea. :) -J --
Re: Hijri Calendar + searching datetime mail archives
Matt Sisk schreef: At some point there was discussion of a Hijri calendar on this mailing list, but I'll be darned if I can find the references. Are you sure? I can't find any discussion (googling on e.g. islamic perl datetime finds only one or two posts), and I can't find anything in my 'sent' folder, and I'm almost sure I would have mailed in such a discussion. There was a mention of the Hejira calendar in a discussion on Business dates; perhaps that's what you remember? Or the Jalali (Persian) calendar is similar to the Hegira calendar, maybe that was it? Anyway, there's some code posted out on perlmonks pertaining to Hijri calendar conversions. I have no idea of the accuracy and it doesn't involve DateTime. Perhaps Alex could be persuaded to work on a DateTime implementation: It probably is accurate; but there are several (different) algorithms to calculate Hejira dates, used by different countries, and all of these are only approximations of the true dates, which are based on observations of the new moon. So we should be careful when we announce a module for _the_ DT::Cal::Hidjra. If necessary, I'm willing to help converting it to a DateTime module; it's not that difficult, as the Gregorian=Hijrah conversion in Alex' module is already done via an absolute (rata-die) date. Eugene
Re: Hijri Calendar + searching datetime mail archives
Eugene van der Pijll wrote: Are you sure? I can't find any discussion (googling on e.g. islamic perl datetime finds only one or two posts), and I can't find anything in my 'sent' folder, and I'm almost sure I would have mailed in such a discussion. Hijri, Hejira, Hidjra...darn if I can figure out why I couldn't find squat on google! :) I'm not overly familiar with these calendars, although I know that the proper ones are lunar-based. As for my memory, I'm no doubt also conflating the Jalali discussion into the mix. It probably is accurate; but there are several (different) algorithms to calculate Hejira dates, used by different countries, and all of these are only approximations of the true dates, which are based on observations of the new moon. So we should be careful when we announce a module for _the_ DT::Cal::Hidjra. Right...I had taken a quick look at his code and knew that it must be a simplified version since it had no lunar component. If necessary, I'm willing to help converting it to a DateTime module; it's not that difficult, as the Gregorian=Hijrah conversion in Alex' module is already done via an absolute (rata-die) date. True. His post caught my eye because he mentioned it had been ported from some KDE code. I wasn't sure if their algo was particularly clever or worth capturing in DT. Cheers, Matt
