Re: About the next version of DateTme::Event::Sunrise

wich Observatory might be considered a higher authority. Alas their website is kind of wonky today, which is ironic since it's Solstice. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux

Re: TimeZones and politics Re: How to tell (in advance) if a date-time is ambiguous?

f he seemingly had leisure time before sunset that meant he should use the time to buy someone else's standing hay and go mow and bale it ! So the stores to which he delivered corn and milk etc changing their hours twice per year inconvenienced him. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux

TimeZones and politics Re: How to tell (in advance) if a date-time is ambiguous?

tical -- splitting the difference between two powerful neighbors,China/Tibet +06 and India(Kolkata) +05:30. Picking either could anger the other neighbor, so split the difference. Yes, it's political. But to us here, the output of the political process is our input data We try to make things be

Re: How to tell (in advance) if a date-time is ambiguous?

On Mon, Jul 10, 2017 at 2:19 PM, Dave Rolsky wrote: > While you could in theory write code that would be correct for all past > datetimes, the future doesn't work the same way. As Eric noted, time zones > are political. I have seen DST transitions altered with mere days (or >

Re: How to check if a DateTime is invalid (again - but this time without using eval)?

competing try-catch modules. https://metacpan.org/search?q=try%2Dcatch​ ​ ( My usual rule of thumb is try a ::Simple​ or ::Tiny variant first :-) But i'm not sure which if any is particularly better or worse adapted to catching DateTime erroneous input errors. Maybe someone else has been

Re: FW: timelocal() discrepancy vs DateTime->epoch

ntil 2007 to get it done.) I predict Lu's script will report DST transitions morning of Apr 2 and Oct 29 in 1906, since those were the dates in 2006. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux

Re: Relative speed of DateTime::SpanSet->contains vs. DateTime::Set->next

(a) if performance isn't really important, do which ever is easier to read and get right ( = unit-test). When you're bug fixing 6-24 months from now future-you will be happier and thank current-you. The 1st general rule is to defer optimization until proven it's needed. [See: Jon Bentley, [more]