Re: Determining next DST transition

2010-07-30 Thread Anthony R. J. Ball
On Fri, Jul 23, 2010 at 04:39:58PM +0100, Elliot Merrony wrote: Hi all I filed this bug last week and Dave Rolsky advised me to post here to explain what I was trying to do: I created a simple lib to do this, though it really should be made available in the main libs. It takes a year or

Re: Help pulling dst change dates from DateTime::TimeZone

2007-03-06 Thread Anthony R. J. Ball
Some of what I'm doing would benefit from this too. I suggest an addition to the DT::TZ API: I'll do a patch to implement this if no one objects. It sounds like a reasonable solution, as long as plugging the current end boundary +1 gives you the next boundary, so you can easily work your

Re: Help pulling dst change dates from DateTime::TimeZone

2007-03-06 Thread Anthony R. J. Ball
I'd prefer multiple methods to a third parameter. Different names provides clarity. Who would know what a number means without looking in the docs? If you want to send a patch with three names, that'd be good, and I can think about what exactly to call it. I'm not sure if boundary is the

Re: Help pulling dst change dates from DateTime::TimeZone

2007-03-06 Thread Anthony R. J. Ball
Presumably we'll go for the lightest form then, just dealing with the transition instants. I definitely want a backward iterator. -prev in DT::TZ::O will require it, of course. This comes back to the interface issues already discussed for the boundary-based interface. When I was looking

Help pulling dst change dates from DateTime::TimeZone

2007-03-05 Thread Anthony R. J. Ball
I want to be able to grab the actual DST change dates for a timezone and year. I haven't seen any calls to do this and was looking at writing my own. I think I see where I can get the data (by following how is_dst work), but it comes out as spans with the time in seconds. Is there a call to