Re: tzdata and Debian
On Wed, 23 Feb 2011, Zefram wrote: We should ask for the libdatetime-timezone-perl package to routinely go the volatile route, the same way the tzdata package does. I believe this request should go to the maintainer of the Debian package, the Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org. Dave, I suppose as the DT-TZ maintainer you should make the request. I am a Debian developer and a member of the pkg-perl group and while I am not personally involved in these packages I do know a little about them. New versions of the DateTime packages get uploaded to the unstable distribution pretty quickly I'd say within week on average. If there are no major bugs, the package then proceeds to the testing distribution after 10 days. There is another the alternative package source, the 'backports' archive' which has become official as of the recently released 6.0 version of Debian. This archive consists of packages from testing backported to the stable distribution. This is probably a more appropriate location than volatile though I suppose there is some overlap in their charters. Backports of the DateTime packages are not made automatically but they do get made pretty regularly afaics. -- Jaldhar H. Vyas jald...@braincells.com
Rounding a DateTime to the nearest minute
Is there a simple way to do this (i.e. 6:14:56 becomes 6:15:00, 6:14:07 becomes 6:14::00 etc.) or do I have to roll my own? -- Jaldhar H. Vyas jald...@braincells.com
Re: Rounding a DateTime to the nearest minute
On Thu, 2 Dec 2010, Rick Measham wrote: This works in my head: $dt-add( seconds = 30 )-truncate( to = 'minute' ); Wonderful! One thing I found out about my data after I wrote is that I need to round down if seconds = 30 exactly. So I just changed your code to add 29 seconds and now it works perfectly. Thanks for your help. -- Jaldhar H. Vyas jald...@braincells.com
Re: DateTime::Calendar::Discordian
On Mon, 11 Jan 2010, Rich Bowen wrote: Long, long ago, I write Date::Discordian, the first of many date/time modules that started my interest in Perl datetime stuff. ... time passes ... Today I was poking around the perl-datetime svn repository, and found DateTime::Calendar::Discordian, which is evidently the current incarnation of that module. But the one that's on CPAN isn't the same one that's in svn, by a LONG shot. I have no idea where that module came from. I maintain the CPAN module and my public git repository is at http://github.com/jaldhar/DateTime-Calendar-Discordian I was wondering if someone could enlighten me as to the current state of this module. It is in a stable, feature-complete state. Unless you have some ideas, I don't think there's really anything more to do to it. -- Jaldhar H. Vyas jald...@braincells.com
What is wrong with this function?
I hope this is not too off topic for the list.
While profiling
DateTime::Indic with Devel::NYTProf, I discovered that my calls to
DateTime::Event::Lunar ::new_moon_before and ::new_moon_after were major
bottlenecks. So I decided to replace them with code which is ultimately
derived from Meeus's Astronomical Algorithms chapter 32. It makes a huge
difference in speed but there is one problem.
Take a look at the output of the short example program below. In most
cases, the DateTime::Event::Lunar functions and my newmoon function give
almost the same results. But every now again newmoon() is off by an
entire lunar cycle. Why is this? How can I fix it?
#!/usr/bin/perl
use strict;
use warnings;
use DateTime;
use DateTime::Event::Lunar;
use DateTime::Event::Sunrise;
use Math::Trig qw/ deg2rad /;
use POSIX qw/ floor /;
my $date = DateTime-new(year = 2008, month = 1, day = 1);
my $sun = DateTime::Event::Sunrise-new(
latitude = '18.96',
longitude = '72.82',
altitude = 0,
);
# year 2008
for (1 .. 366) {
# time of sunrise on $date adjusted for Indian Standard Time
my $sunrise = $sun-sunrise_datetime($date)-set_time_zone('Asia/Kolkata');
# old method
my $pnm1 = DateTime::Event::Lunar-new_moon_before(
datetime = $sunrise,
)-jd;
my $nnm1 = DateTime::Event::Lunar-new_moon_after(
datetime= $sunrise,
)-jd;
# new method
# 0 = previous new moon before $sunrise
my $pnm2 = newmoon($sunrise-jd, 0);
# 1 = next new moon before $sunrise
my $nnm2 = newmoon($sunrise-jd, 1);
my $pnmdelta = $pnm2 - $pnm1;
my $nnmdelta = $nnm2 - $nnm1;
print $sunrise $pnmdelta $nnmdelta\n;
$date-add(days = 1);
}
use constant J1900 = 2_415_020.0;
use constant synodic_month = 29.530_588_68;
sub newmoon {
my ($jdate, $arg) = @_;
my $k = floor((($jdate - J1900) / 365.25) * 12.3685) + $arg;
# time in Julian centuries since J1900
my $t = ($jdate - J1900) / 36525.0;
# square for frequent use
my $t2 = $t*$t;
# cube for frequent use
my $t3 = $t2*$t;
# mean time of phase
my $jdnv = (2_415_020.759_33) + synodic_month * $k + 0.000_117_8 * $t2
- 0.000_000_155 * $t3
+ 0.000_33 * sin(deg2rad(166.56 + 132.87 * $t - 0.009_173 * $t2));
# Sun's mean anomaly
my $m = deg2rad(359.224_2 + 29.105_356_08 * $k - 0.000_033_3 * $t2
- 0.000_003_47 * $t3);
# Moon's mean anomaly
my $mprime = deg2rad(306.025_3 + 385.816_918_06 * $k + 0.010_730_6 * $t2
+ 0.000_012_36 * $t3);
# Moon's argument of latitude
my $f = deg2rad(21.296_4 + 390.670_506_46 * $k - 0.001_652_8 * $t2
- 0.000_002_39 * $t3);
# Correction for new moon
my $djd = (0.1734 - 0.000_393 * $t) * sin($m) + 0.002_1 * sin(2 * $m);
$djd = $djd - 0.406_8 * sin($mprime) + 0.016_1 * sin(2 * $mprime);
$djd = $djd - 0.000_4 * sin(3 * $mprime) + 0.010_4 * sin(2 * $f) ;
$djd = $djd - 0.005_1 * sin($m + $mprime) - 0.007_4 * sin($m - $mprime);
$djd = $djd + 0.000_4 * sin(2 * $f + $m) - 0.000_4 * sin(2 * $f - $m);
$djd = $djd - 0.000_6 * sin(2 * $f + $mprime) + 0.001 *
sin(2 * $f - $mprime);
$djd = $djd + 0.000_5 * sin($m + 2 * $mprime);
$jdnv += $djd;
return $jdnv;
}
--
Jaldhar H. Vyas jald...@braincells.com
Re: What is wrong with this function?
On Fri, 7 Aug 2009, Jaldhar H. Vyas wrote: Take a look at the output of the short example program below. In most cases, the DateTime::Event::Lunar functions and my newmoon function give almost the same results. But every now again newmoon() is off by an entire lunar cycle. To assist anyone willing to help me with this, the incorrect days are: Jan 8 Feb 6 Feb 7 Mar 7 Apr 6 May 5 Jul 3 Dec 27 -- Jaldhar H. Vyas jald...@braincells.com
Re: Timezone lookup?
On Thu, 6 Aug 2009, Mark Theodoropoulos wrote: and yet I don't see any data for the major Indian cities like Mumbai, Calcutta or Delhi. If there are Indian cities represented there, I don't know their names. And THAT strikes me as odd, given that India, by itself, has about a quarter of the world's population and it has some of the world's largest cities. In 1996 we had to learn to replace 'Bombay' with 'Mumbai'; five years later 'Calcutta' became--or rather, changed its official English name back to what its real name has always been--'Kolkata,' but for some reason Western media seem to have ignored that one. There does appear to be a Kolkata in DateTime::TimeZone. Perhaps because Kolkata was never its real name (Kolkata is the Bengali pronounciation of Calcutta the name under which the city was founded by the British.) The local government was suffering from Mumbai envy so they decided they had to decolonialize their name too. Mumbai on the other hand really is Mumbai to its Gujarati and Marathi speaking inhabitants and was so before it was anglicized (strictly speaking Portuguesed) to Bombay. Only the politicians actually care about any of this stuff though. Bombay, Mumbai, Sheboygan call it what you like :-) -- Jaldhar H. Vyas jald...@braincells.com
ANNOUNCE: DateTime-Indic 0.1
I'm pleased to announce that I have uploaded DateTime-Indic 0.1 to CPAN. This version has support for three Indian luni-solar calendars: South Indian Shalivahana Shaka Gujarati vikrama Samvata Halari/Kutchhi Samvata A lot of work remains to be done but given how long I've dragged my feet on this, I thought it would be better to get it out there as soon as it was somewhat usable. I'd love to get some feedback. If you're interested in helping out, I've set up a mailing list here: http://lists.braincells.com/cgi-bin/listinfo/panchanga-devel and the projects website is here: http://code.google.com/p/panchanga/ (includes subversion repository) -- Jaldhar H. Vyas jald...@braincells.com
Re: DateTime::Lite
On Sat, 22 Nov 2008, Daisuke Maki wrote: Hi, I have an RFC/request for blessing for a module. So I have this requirement to make DateTime leaner, in terms of speed, load time, and the amount of memory consumed. The target is for casual users, so the use of XS code is not an option either. Doesn't Time::Piece (core in 5.10) already fill this niche? Ok, it doesn't do the locale and timezone stuff but IMO adding it there would make more sense than a DateTime::Lite. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
On Mon, 24 Nov 2008, Daisuke Maki wrote: No, for 3 reasons: 1. it's XS http://search.cpan.org/src/MSERGEANT/Time-Piece-1.13/Piece.xs Ok yes that would be a dealbreaker. Though if it is part of a default perl installation it is a lot less of a problem for casual users. 2. it would mean different API 3. as you say, it doesn't do everything DateTime can. I doubt if I am the only person who might ask this question. Perhaps you should add a comparison to Time::Piece to the POD? -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
On Mon, 24 Nov 2008, Daisuke Maki wrote: Well, not that I'm trying to be terse... but I need DateTime, not Time::Piece. I need something that resembles DateTime, but faster, leaner, without XS. Time::Piece just wouldn't cut it. Since XS rules out Time::Piece, I still don't see why /not/? Is there any reason why? Now that you have explained it I don't see why not either. However personally I have always thought of Time::Piece as DateTime 'lite' and I am guessing other people might too. So I think an explicit comparison in the docs would be useful. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime From Solar Longitude
On Sun, 22 Jun 2008, Flavio S. Glock wrote: how about: use DateTime::Event::Lunar; use DateTime::Event::SolarTerm; my $new_moon = DateTime::Event::Lunar-new_moon(); my $dt0 = DateTime-today; my $eq = DateTime::Event::SolarTerm-next_term_at( datetime = $dt0, longitude = 0, ); print $new_moon-next( $eq ), \n; Thanks, this is working great with my test data. Though DateTime::Event::Solarterm is failing a bunch of its tests with is a bit worrisome. -- Jaldhar H. Vyas [EMAIL PROTECTED]
DateTime From Solar Longitude
Given a decimal value for solar longitude (such as from DateTime::Util::Astro::Sun::solar_longitude) how would I convert it to a DateTime. Specifically what I want to do is determine the first new moon after the vernal equinox (solar longitude = 0) -- Jaldhar H. Vyas [EMAIL PROTECTED]
Indic calendars
On this auspicious day of Poshi Poonam (full moon of the month of Pausha) I would like to announce that I'm working on implementing various Calendars traditionally used in India for the DateTime API. It's something I've been fitfully working on for a few years now but unlike previous abortive announcements, I actually having working code this time :-) However before I make an upload to CPAN, I would like some advice. I have the following types of modules: Indian calendars are of two types: solar, and luni-solar. There is a base class for each type which would not be used directly but be subsclassed for actual working calendars. There is the actual calendars in historical and contemporary use themselves. There are modules for lunar and solar astronomical calculations. Originally I used the existing DateTime::Util::Astro::* modules but they are really slow and even worse give incorrect results. Whether this is because of a bug in the modules, in my code or some weird math error (I know perl has problems with this.) I don't know but the code I have now (originally based on Jan Meeus's book.) is fast and gives me the correct results. On the downside, it is a barely documented spaghetti mess so I would eventually like to get it replaced with D::A::U if possible. There are modules for localization into different Indian languages. The existing DateTime::Locale framework can't be used because the units of time measurement are different. (e.g. we have fortnights, leap months, etc.) So I was planning on using the following namespaces: DateTime::Calendar::* - e,g. VikramaSamvata, ShalivahanaShakha etc. The actual calendars people use. DateTime::Calendar::Indic::* - e,g. Chandramana (luni-solar) Sauramana (solar) The base classes for the calendars. DateTime::Calendar::Indic::Util::* - e.g. Sun, Moon, Common The support code for the calendars. DateTime::Calendar::Indic::Locale::* - e.g. sn_utf8 (Sanskrit in UTF8), gu_ITRANS (Gujarati in ITRANS transliteration) etc. The i18n code for the calendars. Does this seem ok? -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: Indic calendars
On Wed, 3 Jan 2007, Zefram wrote: I didn't realise there were several. Oh there are about 30 atleast. But mostly they are variants on two basic types. I was fascinated by the lunisolar one described in Calendrical Calculations. Unfortunately the one described there doesn't really match up to anyone used in real life. (They relied on secondary sources which is understandable.) That led me astray for a long time. Looks good to me. Thanks. -- Jaldhar H. Vyas [EMAIL PROTECTED]
RE: Indic calendars
On Wed, 3 Jan 2007, Jim Bacon wrote: This might be out in left field, but ... Is it conceivable, or possible, that someone might use the modules from the Indic namespace to create other modules in the DateTime::Event namespace? Oh this is a good point. Yes it is quite likely. In fact I can think of some ideas. If so, then it might be reasonable to leave only the actual calendar modules in D::C and place all the other in DateTime::Indic as support modules. I agree. Dave is a new DateTime::Indic namespace ok? I mention this mainly because of the presence of your solar/luni-solar support modules alongside of the actual calendars in the D::C namespace. This seems like it could lead to confusion. Well as I mentioned I would ideally like that code to go away and I'm not completely sure how good it is only that It Works For Me(tm) so I have been treating it as private but your point is valid. -- Jaldhar H. Vyas [EMAIL PROTECTED]
RE: Indic calendars
On Wed, 3 Jan 2007, Dave Rolsky wrote: On Wed, 3 Jan 2007, Jaldhar H. Vyas wrote: If so, then it might be reasonable to leave only the actual calendar modules in D::C and place all the other in DateTime::Indic as support modules. I agree. Dave is a new DateTime::Indic namespace ok? There's already some bits in DateTime::Util for handling various types of calculations. It's seems like this is something similar, so maybe DateTime::Util::Indic? And DateTime::Locale::Indic for the locales? -- Jaldhar H. Vyas [EMAIL PROTECTED]
[ANNOUNCE] DateTime::Calendar::Discordian 0.9.2
I just uploaded a new version of this module to CPAN. This version fixes an off by one error in the conversion of St. Tib's Day to an RD date. -- Jaldhar H. Vyas [EMAIL PROTECTED]
ANNOUNCE: DateTime::Calendar::Discordian 0.9.1
Rich Bowen has agreed to let me handle this module so I've uploaded version 0.9.1 to CPAN. For those who don't know about the Discordians or their calendar see http://www.ology.org/principia/ or the Illumunatus! trilogy by Shea and Wilson. -- Jaldhar H. Vyas [EMAIL PROTECTED]
DateTime::Calendar::Discordian
While malingering from actual work, I wrote some code to convert dates to and from the Discordian calendar. Over the past couple of nights I made it into a proper DateTime::Calendar module which I posted to PerlMonks (http://www.perlmonks.org/index.pl?node_id=362936) This morning I also packaged it up into a proper CPAN package which you can find at http://src.braincells.com/perl/ Before I upload it to CPAN, I'd like you to review it and suggest any improvements, bugfixes etc. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Calendar::Discordian
On Thu, 10 Jun 2004, Dave Rolsky wrote: Well, Rich Bowen had started working on the same module, so you should talk to him. Reviewing the code/docs, I have a couple nits: Oh yeah I just saw that in the list archives. - The constructor shouldn't take rd_secs, rd_nanosecs, or locale, I don't think. The only way to set this should be via the from_object method. Ok. I'll change that. - I'm assuming that the holyday spelling is intentional, right? Yes. That seems to be the way Discordian texts spell it. - days_till_x should be days_until_x. I'm not a big fan of abbreviations in general, unless they're ridiculously obvious, and till is the wrong abbreviation anyway ;) Ok. I'll change that. - You have %% documented twice. - Using uuml; in the exclamations probably isn't right. This is part of Latin-1, so use that character. I think both of these are artifacts from cutting and pasting from PerlMonks but I'll make sure they are fixed. Apart from being an enjoyable little waste of time, this module is just a warmup for the Hindu calendars I said I was going to do a long time ago. -- Jaldhar H. Vyas [EMAIL PROTECTED]
