Re: Timezone lookup?
On Thu, August 6, 2009 7:42 am, Ted Byers wrote: Isn't it odd that, in the Asia data, there are values for Gaza and Jerusalem, which are only a short distance apart (in terms of how far a crow would have to fly to travel between them, not politically), or more odd, Kuala Lumpur and Singapore (which are separated only by a narrow channel), 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. And yet, in the american data, there are values for Glace Bay, Goose Bay, Thunder Bay, Whitehorse. It seems strange that what are tiny little villages are represented while such huge cities are not. While the zones eschew using country as part of the name (because countries change names much more often than cities do), what is logically one zone, with consistent offset and dst rules, is represented in the database by multiple zones, one per country (because the legal changes to offset/dst rules often happen by country, and otherwise what is one zone now would be two zones tomorrow much more often). Within each zone, the most recognizable city is used as the name. In some cases, this isn't the largest. See the comments in the region files for rationales, for instance: # IATA SSIM (1993-02/1994-09) say that the Holiday Islands (Hayman, Lindeman, # Hamilton) observed DST for two years after the rest of Queensland stopped. # Hamilton is the largest, but there is also a Hamilton in Victoria, # so use Lindeman.
Re: Timezone lookup?
On Wed, August 5, 2009 12:52 pm, Ted Byers wrote: Is there, in the various timezone packages, support somewhere for finding out what the timezone is for a given city/state? I have, in my database, extensive data with the usual contact information from users from around the world. If at all possible, I would like to query the data managed by one of the timezone packages to determine the local users' timezones from their mailing address. Is this possible? Using what? For countries with a single timezone, you can look it up by iso3166 two character code in %DateTime::TimeZone::Catalog::ZONES_BY_COUNTRY. For other countries, I don't know of such support. You can read the comments in zone.tab or the longer comments in the region files in the tzdata package at ftp://elsie.nci.nih.gov/pub/.
Re: Item #1 returned by STORABLE_freeze for DateTime is not a reference
On Mon, July 13, 2009 6:13 pm, Bill Moseley wrote: (in cleanup) Item #1 returned by STORABLE_freeze for DateTime is not a reference at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_freeze.al) line 339 during global destruction, at line 327 It's expected that this nfreeze is happening in a DESTROY() (the data gets serialized and stored upon destroy). Is the destroy a red herring? Order of destruction during global destruction isn't guaranteed; it's entirely possible there are important bits of Storable gone by the time your DESTROY is called. Arrange your scopes such that any important DESTROY happens before global destruction.
Re: DateTime::Lite
On Sat, November 22, 2008 12:50 am, Daisuke Maki wrote:
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.
In terms of speed, one of the things that's unique (AFAIK) to
DateTime is being able to thread-safely convert a datetime from
one timezone to another.
I'd be curious to know how it fares in this regard. Here's a
benchmark that for me shows DateTime proper almost ten times as
slow as non-thread-safely using libc routines (suggestions for
improvement enthusiastically welcomed):
#!/usr/bin/perl -l
use strict;
use warnings;
use DateTime;
use Env::C;
use POSIX mktime;
sub convert_timezone_datetime {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
my $dt = DateTime-new(year=$y, month=$mo, day=$d, hour=$h,
minute=$m, second=$s,time_zone=$tz);
$dt-set_time_zone($new_tz);
return map $dt-$_, qw/year month day hour minute second/;
}
sub convert_timezone_env_c {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
my $save_tz = Env::C::getenv(TZ);
Env::C::setenv(TZ,$tz,1);
my $time = POSIX::mktime($s,$m,$h,$d,$mo-1,$y-1900,0,0,-1);
Env::C::setenv(TZ,$new_tz,1);
POSIX::tzset(); # localtime_r bug
($s,$m,$h,$d,$mo,$y) = localtime($time);
$mo++; $y+=1900;
# this belongs in a destructor
if (defined $save_tz) { Env::C::setenv(TZ,$save_tz,1) }
else { Env::C::unsetenv(TZ) }
return ($y,$mo,$d,$h,$m,$s);
}
sub convert_timezone_system {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
local $ENV{TZ} = $tz;
my $time = POSIX::mktime($s,$m,$h,$d,$mo-1,$y-1900,0,0,-1);
$ENV{TZ} = $new_tz;
POSIX::tzset(); # localtime_r bug
($s,$m,$h,$d,$mo,$y) = localtime($time);
$mo++; $y+=1900;
return ($y,$mo,$d,$h,$m,$s);
}
print join ,,
datetime=convert_timezone_datetime(2008,7,3,23,2,3,America/Denver,America/New_York);
print join ,,
registry=convert_timezone_env_c(2008,7,3,23,2,3,America/Denver,America/New_York);
print join ,,
system=convert_timezone_system(2008,7,3,23,2,3,America/Denver,America/New_York);
use Benchmark timethese;
timethese(-5, {
datetime = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_datetime(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
env_c = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_env_c(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
system = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_system(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
} );
Re: DateTime::Lite
On Sat, November 22, 2008 2:26 am, Daisuke Maki wrote: oops, forgot the SVN url http://svn.coderepos.org/share/lang/perl/DateTime-Lite/trunk Could we have a working tarball, please? I gave up after a very brief attempt to install and use Module::Install.
Re: DateTime::Lite
On Sun, November 23, 2008 9:09 pm, Daisuke Maki wrote: http://users.endeworks.jp/~daisuke/DateTime-Lite-0.1.tar.gz As noted before, the timezone/locale stuff are not fully portable yet, so you need to be in the distro's root directory for DateTime::Lite to be usable. Nice. 38% faster than DateTime at converting timezones. Can't wait for DateTime::Lite::XS (*ducks*)
Re: missing something..part 2
Zefram wrote: Matthew wrote: Hehe. I'm the DBA. And I've updated everything to most recent stuff, but the boss man wants generic time zones in our list just in case a customer can't find his or doesn't realize his city is listed differently. Unlikely to ever occur. As far as anyone knows, the Olson zoneinfo database contains all currently-distinct timezones. (It explicitly aims to include all timezones that have been distinct at any time since 1970.) You might want to play with the tzselect(8) program, which guides one through selecting a geographical timezone from the database. I don't think you read all the way to the end of Matthew's paragraph. But FWIW, the Olson etcetera file has this to say: # These entries are mostly present for historical reasons, so that # people in areas not otherwise covered by the tz files could zic -l # to a time zone that was right for their area. These days, the # tz files cover almost all the inhabited world, and the only practical # need now for the entries that are not on UTC are for ships at sea # that cannot use POSIX TZ settings. -- I'm looking for a job: http://perlmonks.org/?node=ysth#looking
Re: Daylight Saving
On Thu, Feb 09, 2006 at 12:05:42PM -0800, Bill Moseley wrote: On Fri, Jan 20, 2006 at 07:26:16AM -0800, Bill Moseley wrote: I have a zipcode table that lists the city, state, timezone offset (eg -5) and a flag indicating if the location uses daylight saving time for U.S. zipcodes. I don't have the Olson name in the table. How do I set the timezone in this case -- taking into account the dst settings? I kind of left this hanging. Is it possible to set a timezone on a DateTime object based on only the above information? Seems like one would need to know more (such as when Daylight Saving is in effect for that location. But, if so, could I see an example? Yes, it's possible. I assume the timezone offset is the non-dst offset. I'm not sure if Samoa uses US zipcodes :) Offsetdst flagOlson zone -11 no US/Samoa or Pacific/Pago_Pago -10 no HST or US/Hawaiior Pacific/Honolulu -10 yes US/Aleutian or America/Adak -9yes US/Alaskaor America/Anchorage -8yes PST8PDT or US/Pacific or America/Los_Angeles -7no MST or US/Arizona or America/Phoenix -7yes MST7MDT or US/Mountain or America/Denver -6yes CST6CDT or US/Central or America/Chicago -5no EST or US/East-Indiana or America/Indiana/Indianapolis -5yes EST5EDT or US/Eastern or America/New_York I'm pretty sure the missing combinations of offset/dst flag don't exist in the US. DateTime-TimeZone includes the first and third columns of zone names; I'm not sure why it doesn't include those in the second column. For your amusement, the Olson files have this comment (among others) about DST usage in the Falkland Islands: # I know one lady there that keeps a list of which farm keeps DST and # which doesn't each year. She runs a shop in Stanley, and says that # the list changes each year. She uses it to communicate to her # customers, catching them when they are home for lunch or dinner.
Re: Daylight Saving
On Sat, Jan 21, 2006 at 01:20:09PM -0600, Dave Rolsky wrote: On Fri, 20 Jan 2006, Yitzchak Scott-Thoennes wrote: Just use the Olson PST8PDT MST7MDT MST CST6CDT EST5EDT EST zones. I assume there aren't PST and CST zones because they aren't actually in use, but if they are needed, maybe you could use DateTime::TimeZone::OffsetOnly? Is there a reason the Olson etcetera file isn't included in DT::TZ? Is this related to the above quesiton? The etcetera file doesn't define any of those zones. They're all defined either as links or real zones in northamerica. The above are links in the file backward. But etcetera includes non-DST zones Etc/GMT-14 through Etc/GMT+12, which I thought might be useful if in fact someone does need pacific or central time without DST.
Re: Daylight Saving
On Fri, Jan 20, 2006 at 10:59:50AM -0500, Garrett, Philip (MAN-Corporate) wrote: -Original Message- From: Bill Moseley [mailto:[EMAIL PROTECTED] Sent: Friday, January 20, 2006 10:26 AM To: datetime@perl.org Subject: Daylight Saving I have a zipcode table that lists the city, state, timezone offset (eg -5) and a flag indicating if the location uses daylight saving time for U.S. zipcodes. I don't have the Olson name in the table. How do I set the timezone in this case -- taking into account the dst settings? It looks like DateTime::TimeZone doesn't support offsets with DST. You could use a brute force approach where you choose a single Olson name to go with each offset/dst combination. e.g. (just guessing at these) GMT-0500(DST) = America/New_York GMT-0500 = America/Indiana/Indianapolis GMT-0800(DST) = America/Los_Angeles Then, put that Olson name in the table and use it. It's not exactly elegant, but it'd probably get you what you want. Just use the Olson PST8PDT MST7MDT MST CST6CDT EST5EDT EST zones. I assume there aren't PST and CST zones because they aren't actually in use, but if they are needed, maybe you could use DateTime::TimeZone::OffsetOnly? Is there a reason the Olson etcetera file isn't included in DT::TZ?
Re: DateTime performance
On Mon, Jan 16, 2006 at 06:21:54PM -0800, [EMAIL PROTECTED] wrote:
One might hope that a script like this:
test3
#!/usr/bin/perl
BEGIN {
no lib qw|/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/
lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/
site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/
5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6 /usr/lib/
perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/
site_perl/5.8.3 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/
5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-
linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-
multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/
lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/
perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/
perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-thread-multi /usr/
lib/perl5/5.8.6 .|;
use lib qw|/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /
usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl /usr/lib/perl5/
vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/
5.8.6 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-
thread-multi /usr/lib/perl5/5.8.6 .|;
}
use DateTime;
Might improve the situation. However even this has no significant
improvement and from additional traces it doesn't actually stop perl
from using the built in paths.
Then no lib isn't doing what you want. Try just:
BEGIN { @INC = grep !/5\.8\.[0-5]/, @INC }
Re: DateTime performance
On Wed, Jan 18, 2006 at 08:38:13AM -0800, [EMAIL PROTECTED] wrote:
Then no lib isn't doing what you want.
Agree. But, that is the point. Outside of recompiling perl with new
paths or significantly altering DateTime to use far fewer
dependancies nothing can really be done.
test4
#!/usr/bin/perl
BEGIN { @INC = grep !/5\.8\.[0-5]/, @INC }
use DateTime;
Do your traces show it still searching all the removed paths?
There's no way the above should be doing that, unless you're
loading DateTime earlier, via sitecustomize.pl or $PERL5OPT?
Re: hires DateTime-from_epoch( epoch = ... ) values
On Mon, Aug 08, 2005 at 09:31:10AM -0500, Dave Rolsky wrote: On Mon, 25 Jul 2005, Joshua Hoblitt wrote: a) do nothing... nobody else seems to have noticed b) document the limited precision issue c) change the API to some awful Fortranish a part + b part to preserve precision d) turn the epoch parameter into a Math::BigFloat so a high resolution 'string' can be passed in and document the behavior. It's not clear to me what the right solution is although a patch to implement option d sans the required documentation changes is attached. That seems right to me. Does anyone object to adding Math::BigFloat as a prereq? You may want to require a recent version; Tels has done a great job maintaining the Math::Big* modules, but AIUI they started off (and were shipped in older perls) with quite a few bugs.
FYI: new leap second on its way
- Forwarded message from [EMAIL PROTECTED] - INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 e-mail: [EMAIL PROTECTED] http://hpiers.obspm.fr/eop-pc Paris, 4 July 2005 Bulletin C 30 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 2006 A positive leap second will be introduced at the end of December 2005. The sequence of dates of the UTC second markers will be: 2005 December 31, 23h 59m 59s 2005 December 31, 23h 59m 60s 2006 January 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 1999 January 1, 0h UTC, to 2006 January 1 0h UTC : UTC-TAI = - 32s from 2006 January 1, 0h UTC, until further notice : UTC-TAI = - 33s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Head Earth Orientation Center of IERS Observatoire de Paris, France - End forwarded message -
Re: ANNOUNCE: DateTime 0.28
On Sun, Feb 27, 2005 at 11:58:22PM -0600, Dave Rolsky wrote: 0.282005-02-27 [ ENHANCEMENTS ] - The era names for the era() method are now retrieved from the DateTime.pm object's associated locale. The old era() method, which was hard-coded to use BCE and CE, is renamed secular_era(). Why? I thought one of the selling points of CE was that people were free to interpret it as Xtian Era or Common Era as they please. I'd have left it as generic era().
Re: Bug: DT::Event::Recurrence Modifies Params
On Wed, Jan 19, 2005 at 04:59:33PM +, [EMAIL PROTECTED] wrote:
Daisuke wrote:
+sub _sort_positive_first
+{
+my @sorted = sort { $a = $b } @_;
+# put positive values first
+my @ret = grep { $_ = 0 } @sorted;
+push @ret, $_ for grep { $_ 0 } @sorted;
+
+return @ret;
+}
I rewrote the sort:
@args = sort {
$a 0 ? ( $b 0 ? $a = $b : 1 ) :
( $b 0 ? -1 : $a = $b )
} @args;
DateTime::Event::Recurrence was uploaded to CPAN as
version 0.15.
I added a test for modified parameter.
YMMV, but I find something like this more clear:
@args = sort { ($a 0) = ($b 0) || $a = $b } @args;
(literally, sort first by positive/negative, then by value).
Re: Bug: DT::Event::Recurrence Modifies Params
On Sat, Jan 08, 2005 at 09:56:38AM +0900, Daisuke Maki wrote:
+sub _sort_positive_first
+{
+my @sorted = sort { $a = $b } @_;
+# put positive values first
+my @ret = grep { $_ = 0 } @sorted;
+push @ret, $_ for grep { $_ 0 } @sorted;
push takes a list; make that
push @ret, grep { $_ 0 } @sorted;
+
+return @ret;
+}
Re: DateTime::Duration 'in_units' does not properly normalize units
On Mon, Dec 13, 2004 at 07:04:23PM -0600, Dave Rolsky [EMAIL PROTECTED] wrote: On Mon, 13 Dec 2004, Dave Rolsky wrote: How can that be sane? So you ask for minutes and you get fractional minutes but you ask for seconds and get zero? Cause really it should just blow up when you give it fractional anything. Or not. Anyone know of a good way to check that a parameter is one of: - an integer int($param) != $param # works even for values greater than max UV - infinity - NaN $param - $param != 0; # indicates +/-Inf or NaN (differentiate between the two: $param != $param ? nan : infinite) keeping in mind that if I regex a very large number it gets converted to a string which may be 1.5853e+18!
Re: DateTime::Duration 'in_units' does not properly normalize units
On Mon, Dec 13, 2004 at 06:14:12PM -0800, Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote: On Mon, Dec 13, 2004 at 07:04:23PM -0600, Dave Rolsky [EMAIL PROTECTED] wrote: On Mon, 13 Dec 2004, Dave Rolsky wrote: How can that be sane? So you ask for minutes and you get fractional minutes but you ask for seconds and get zero? Cause really it should just blow up when you give it fractional anything. Or not. Anyone know of a good way to check that a parameter is one of: - an integer int($param) != $param # works even for values greater than max UV ==, not != :) - infinity - NaN $param - $param != 0; # indicates +/-Inf or NaN (differentiate between the two: $param != $param ? nan : infinite) keeping in mind that if I regex a very large number it gets converted to a string which may be 1.5853e+18!
Re: Activestate PPMs for DateTime?
On Tue, Nov 02, 2004 at 10:48:19AM -0600, Dave Rolsky wrote: Clearly the easiest for AS is to simple install Module::Build and its dependencies before trying to build PPMs. Agreed. But IIRC it has no non-core dependencies. What's the way forward in all this? I don't know. I do know that the Module::Build people are working on what I assume will be a separate module to parse complex dependency information out of META.yml. We'll see how it goes, and if various tools will adopt it. I don't hold my breath. You hold your breath on it getting written, or getting adopted? It'll get written, I'm sure. Whether people will adopt it is up to them. Sorry to be unclear. I know they are motivated to get it written. I meant whether it will be adopted. Module::Build already has it's own way to tell about dependencies but afaik no one uses it except CPANPLUS.
Re: What is the current state of installing DateTime?
On Mon, Aug 16, 2004 at 09:34:16PM -0700, Ron Pero [EMAIL PROTECTED] wrote: I will ask ActiveState about a better version of the DateTime module for their repository. You can look at what their automated build came up with at: http://ppm.activestate.com/BuildStatus/5.8-D.html (5.8 builds for modules beginning with D). Looking at the failure for windows, you see: failed building DateTime prerequisite DateTime-Locale aborting build of DateTime: failed prerequisites and DateTime-Locale fails because it uses a passthrough Makefile.PL that requires user interaction to download Module::Build. (Activestate's build process does check dependencies and would process Module::Build first if it were a listed as a dependency, but it's not.) This is a fundamental problem with passthrough or small compatibility Makefile.PLs, and an excellent reason to not use them.
Re: What is the current state of installing DateTime?
On Tue, Aug 17, 2004 at 03:56:07AM -0500, Dave Rolsky [EMAIL PROTECTED] wrote: On Tue, 17 Aug 2004, Yitzchak Scott-Thoennes wrote: and DateTime-Locale fails because it uses a passthrough Makefile.PL that requires user interaction to download Module::Build. (Activestate's build process does check dependencies and would process Module::Build first if it were a listed as a dependency, but it's not.) This is a fundamental problem with passthrough or small compatibility Makefile.PLs, and an excellent reason to not use them. They could just install Module::Build once on their machines and be done with this problem! AFAICT, they do each build in a clean environment with only those modules that are listed as dependencies installed. And the ExtUtils::MakeMaker Way of Doing Things is that Makefile.PL has to be run *first* and then dependencies be checked. This makes non-traditional compatibility Makefile.PL's something of a joke, since there is no way for them to be compatible under automated build tools. I did nag an ActiveState person about this at OSCON and he said that someone was working on re(writing|factoring) the auto-PPM tool. One thing you can do is add build_requires: Module::Build to META.yml. Don't know if their tool even checks this file, but it seems to me incorrect to not have it listed.
Re: question on DST
On Fri, Aug 06, 2004 at 08:22:20PM +0700, David Garamond [EMAIL PROTECTED] wrote: I live in a country (and continent) that doesn't observe DST and thus am wondering: I can't help but wonder what continent that is; AFAIK every continent except perhaps Antarctica uses DST somewhere. 1. is DST always (or was, historically; or will be, in the future) started at 02:00AM - 03:00AM and ended at 03:00AM - 02:00AM? No. 2. Are there cities/territories that recently switched from observing DST to not (or vice versa)? Yes.
Re: Windows PPM release of DateTime?
On Wed, Apr 14, 2004 at 06:55:26AM +0200, Christian Hansen [EMAIL PROTECTED] wrote: Robert Eden wrote: Has there been any progress on a windows PPM release? (or fixing whatever problem the automated tool has) It seems that ActiveStates build tool fails on DateTime::Locale [1] and since DateTime depends on it, every DateTime module fails [2]. [1] http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/DateTime-Locale-0.09.txt [2] http://ppm.activestate.com/BuildStatus/5.8-D.html Hmm. Looks to me like ActiveState should use Build.PL in preference to Makefile.PL when both exist. Or is the problem that nothing is indicating that Module::Build is a dependency of DateTime-Locale?
Re: Latitude/Longitude to Olson timezone name
On Fri, Mar 26, 2004 at 12:51:20AM -0600, Ed Perrone [EMAIL PROTECTED] wrote: I am working on an application where the user will input a date, time, and location, and I will need to convert that time into the equivalent GMT. This means I will need to locate the input data within one of the Olsen time zones in order to create and manipulate a Date::Time object. Unfortunately, city/province/nation or latitude/longitude don't seem to convert easily into the time zone names used in Date::Time. Example: User inputs May 15, 1973, Austin, TX, USA. I need to figure out which of the Olsen zones Austin TX is located in. I will have available the city/state-province/nation name, as well as ISO-3166-2 codes for US/Canada states/provinces, FIPS 10-4 codes for other nations/regions, and longitude/latitude of the specific place in question. What I need to find from this is the proper time zone to use for that date/location. Does anyone know of any tool or routine that might be able to do this type of conversion? Many thanks! You could go through the comments in the Olson files; they will say where the timezones apply, and you should be able to come up with a pretty good state/nation-timezone table. (If you do this, please post it here.) For some of the U.S. states, it is helpful to know the county. There's also a zone.tab file that gives latitude/longitude for the cities the timezones are named after. As a last ditch guess, you could pick the one that's closest. The original files can be found at: ftp://elsie.nci.nih.gov/pub/tzdata2003e.tar.gz
Re: Latitude/Longitude to Olson timezone name
On Sun, Mar 28, 2004 at 04:32:43PM +0200, Eugene van der Pijll [EMAIL PROTECTED] wrote: Yitzchak Scott-Thoennes wrote: You could go through the comments in the Olson files; they will say where the timezones apply, and you should be able to come up with a pretty good state/nation-timezone table. (If you do this, please post it here.) For some of the U.S. states, it is helpful to know the county. There's also a zone.tab file that gives latitude/longitude for the cities the timezones are named after. As a last ditch guess, you could pick the one that's closest. There is also another .tab file (I've forgotten its name) in the Olson distribution that contains a list of countries (ISO 2-letter codes) and corresponding timezones. This could perhaps be converted automatically to timezone aliases. Those are in zone.tab also.
Re: patch to DT::F::Builder
On Thu, Jan 29, 2004 at 04:41:41PM -0800, Daisuke Maki [EMAIL PROTECTED] wrote:
It was really annoying me that parsers based on DT::F::Builder would by
default report a parse failure as being in DT::F::B::Parser.
I'd like the error message to tell me where in the calling script it
failed, so I'd like to introduce this patch.
Index: lib/DateTime/Format/Builder.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Format-Builder/lib/DateTime/F
ormat/Builder.pm,v
retrieving revision 1.35
diff -d -u -r1.35 Builder.pm
--- lib/DateTime/Format/Builder.pm 26 Jan 2004 18:46:45 - 1.35
+++ lib/DateTime/Format/Builder.pm 30 Jan 2004 00:37:34 -
@@ -200,6 +200,13 @@
sub on_fail
{
my ($class, $input) = @_;
+
+my $i = 0;
+while (my ($pkg) = caller($i++)) {
+last if ($pkg ne 'DateTime::Format::Builder'
+$pkg !~ /^DateTime::Format::Builder::Parser/);
+}
+local $Carp::CarpLevel = $i;
croak Invalid date format: $input;
}
CarpLevel is (at least semi-) deprecated. Consider using @CARP_NOT.
Re: patch to DT::F::Builder
On Fri, Jan 30, 2004 at 12:18:51AM -0600, Dave Rolsky [EMAIL PROTECTED] wrote:
On Thu, 29 Jan 2004, Daisuke Maki wrote:
Can't this be done with the @CARP_NOT variable?
Hmmm, I was trying to do this:
sub on_fail {
my($class, $input) = @_;
local @Carp::CARP_NOT = qw( PKGS ... );
croak $input;
}
But somehow the messages where unaltered, so now I look at Carp.pm from
my perl 5.8.3, and I see the following:
sub shortmess { # Short-circuit longmess if called via multiple packages
{ local $@; require Carp::Heavy; } # XXX fix require to not clear [EMAIL
PROTECTED]
# Icky backwards compatibility wrapper. :-(
my $call_pack = caller();
local @CARP_NOT = caller(); # RIGHT HERE
shortmess_heavy(@_);
}
Hmph. local @CARP_NOT = caller()?
It's overriding @CARP_NOT regardless of what the caller has done...?
Dave, mind if I just fall back to what I initially proposed?
Sure, that's fine. Looks like Carp is a bit broken.
That bit sets @Carp::CARP_NOT. In your code you should be setting
@Your::Module::CARP_NOT. It's intended to be set just once, like
@ISA, not just before calling carp.
Re: DateTime::TimeZone problems on FreeBSD
On Thu, Dec 04, 2003 at 09:00:54PM +0100, Anton Berezin [EMAIL PROTECTED] wrote: For example, EST is used for Eastern Standard Time, aka America/New_York, but also for parts of Australia. Even EST in the US is ambiguous, because it's also used for America/Indianapolis, a time zone that does not observe DST, in addition to America/New_York, which does observe EST. There's been discussion about this on the list, but I'll repeat this over and over. The various 3 and 4 letter abbreviations sometimes used colloquially for time zones are often not sufficient to accurately determine what the actual time zone is, and should only be used for display purposes, as in January 4, 2003 11:00 EST. Setting your system's time zone to such a thing is asking for trouble. I really don't know. Three-letter abbreviations are POSIX.1. They might be obsolete, but they are still supported by most implementations, and used widely. Umm, a posix-style TZ looks like this: stdoffset[dst[offset][,start[/time],end[/time]]] So at minimum you would have TZ=CET-1 (std and offset). (Note that the offsets are negative east of GMT and positive west of GMT.) If you are using just TZ=CET, I suspect you *do* have an Olson tz entry for CET. Indeed, I see one in tzdata/europe: # These are for backward compatibility with older versions. # Zone NAMEGMTOFF RULES FORMAT [UNTIL] ZoneWET 0:00EU WE%sT ZoneCET 1:00C-Eur CE%sT ZoneMET 1:00C-Eur ME%sT ZoneEET 2:00EU EE%sT It would be nice to have an option to include all the backward-compatibility timezones in DateTime.
Re: solar_longitude_after or modulo question
On Thu, 23 Oct 2003, Daisuke Maki wrote:
Okay, I feel stupid asking this, but I have a question about a basic
function, mod.
My ported computations from CC become all wrong if I use Perl's built-in
% operator. After a few trial and errors, it seemed like when CC mentions
R = N mod M
it's actually computing a fractional number. For example, 15.1 mod 4
would be 3.1. If I take that to be true, most of my computations work.
However, now I'm having problems with taking a modulo of a negative value.
Specifically, I'm trying to implement solar_longitude_after() (p.184)
function -- but it chokes when the difference between $phi and
solar_longitude($t) is a negative number to compute the value of $tau:
$tau = $t + $rate * mod($phi - solar_longitude($t), 360);
It seems like the output of mod() is expected to be something other than
what I've been computing... (The reason I suspect that is because the
solar terms that are generated by this function turns out wrong only if
$phi - solar_longitude($t) is negative ).
Does anybody know how this is supposed to work? I tried a bunch of
things, but I just can't seem to get it right. Does anybody know how
this *should* be done?
Of the top of my head, I recall that CC defines their mod function's
operation up front (in chapter 1? can't find my copy). I think they
always want a positive floating point result. Perl's ($x%$y) will
always give a positive result, but with $x and $y both truncated
zeroward to an integer. POSIX::fmod will do floating point, but
it gives negative results for negative $x.
I think you need to roll your own.
sub cc_mod { $_[0] - $_[1] * POSIX::floor( $_[0]/$_[1] ) }
If you want to avoid use POSIX, floor is pretty easy:
sub floor { int($_[0]) - ( int($_[0]) $_[0] ) }
Caveats: all code untested, no consideration of negative $y, comments
about % don't apply if under 'use integer' where deliberately ambiguous
C standard applies instead.
Re: New Release: DateTime::Calendar::Hebrew
On Tue, Sep 23, 2003 at 05:04:22PM -0400, Steven J. Weinberger [EMAIL PROTECTED] wrote: Just in time for the Hebrew new year (5764, this Friday evening) - DateTime-Calendar-Hebrew-0.01.tar.gz has just been uploaded to PAUSE. Enjoy. In README.hebrew you mention: Understanding the Jewish Calendar by Rabbi Nathan Bushwick. Moznaim Publishing Corporation. ISBN 0-94011-817-3 - Another excellent book. Explains the calendar, lunation cycles, torah portions and more. This has more Astronomy than any of the others. This is a very lucid book. My copy (dated 1989 with no ISBN), has a couple handwritten corrections you might like to know about: On the table on page 96, in the far right column, Day of Pesach is changed from vav to gimmel and for a regular year after a leap year, Friday 6:00pm 408 chalakim is changed to Thurs. night 6:00pm 408 chalakim. On page 102: But in a year during which Shavous fell on Monday or Wednesday, Naso was already read on the Shabbos before Shavous, so there are only nine Sidros left for the 9 Shabbasos is changed to But in a year during which Shavous fell on Monday or Wednesday, if Naso was already read on the Shabbos before Shavous, there are only nine Sidros left for the 9 Shabbasos.
Re: infinity stringification bug in Perl 5.9.0?
On Wed, Sep 03, 2003 at 11:23:44PM +, [EMAIL PROTECTED] wrote: I've got a report that Perl 5.9.0 stringifies infinity and minus infinity with extra spaces, like this: -Inf Inf Is this a bug? Works correctly for me. What do perl -V and perl -V:d_Gconvert say for the offending perl?
Re: DateTime::Duration, length of a month?
On Sat, 5 Apr 2003 12:05:15 +0200, [EMAIL PROTECTED] wrote: Joshua Hoblitt schreef: When converting a DateTime::Duration month to days - how many days should it be considering equivalent too? 30? 30.4? 31? If you want to do this, you have to take into account that a duration of $x years is translated to 12*$x years internally. If your calendar has ^ assume you mean months here no months, it should calculate the number of days to add as $delta_days + int( $delta_months * $DAYS_IN_YEAR/12 ); Problem with the Mayan calendar: it has no years either... But one of the smaller counts (haab) is 365 days long, I believe. So that is probably the Mayan idea of a year. (As usual) I disagree with Dave: some people would find it useful to use durations in any calendar, so why not implement them. As long as they use days and years only, there is no problem. And if they try to add a number of months to a Mayan date, they shouldn't complain about the result. I think I wrote the part of Date::Ical that originally did the x years = 12*x months translation, and I repent. A duration object should not merge its creating parameters into just seconds, days, and months buckets. This is much to Gregorian-centric.
Re: DateTime bug default timezone
On Tue, 11 Mar 2003 10:46:32 -0800, [EMAIL PROTECTED] wrote: On Monday, March 10, 2003, at 07:10 PM, Dave Rolsky wrote: On Sat, 1 Mar 2003, Bruce Van Allen wrote: I agree with these thoughts and principles, but thinking of months as discrete units also has complications, as you say, with weird unpredictable results: [snip] That's why there is an eom_mode (end of month mode) parameter for the DateTime::Duration constructor, which allows you to control how adding months is handled. I think the parameter got renamed to end_of_month. Excellent. - Bruce In your examples, you showed a business month=30 days calculation. Should we have such a 'business' mode? Existing modes are wrap (the default), limit, and preserve: Assuming adding X months to month M, day D: wrap will give D-1 days after the first of month M+X limit will give month M+X with the day being the earlier of D and the last day of the month preserve will give the last day of month M+X if D is the last day of M; otherwise it will give the same result as limit On another topic, just below add_duration in DateTime.pm, I see this: use constant INFINITY = 100 ** 100 ** 100 ; use constant NEG_INFINITY = -1 * (100 ** 100 ** 100); I remember this (how to produce an numeric infinity) coming up on perl5-porters and seem to recall that the above just coredumps on some platforms.
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, 5 Feb 2003 15:52:46 -0600 (CST), [EMAIL PROTECTED] wrote: The DateTime tests do not fully exercise DateTime::TimeZone (nor would you expect them to). So, how about including only those portions of DT::TZ which are required to pass the DT tests. At a quick glance, that would be TimeZone.pm, UTC.pm, Floating.pm, America/Chicago.pm, and America/NewYork.pm. For that matter, since you know exactly what tests are being performed, you can include exactly the portions of the OlsonDB that are used in the DateTime tests and no more. It seems rather arbitrary to only include Chicago and New York. I can just see all the questions about why the others aren't included! Include them in the distribution for testing purposes but don't install them. It might be best to just skip those tests if the DateTime::TimeZone package isn't installed, though. Even better. The TimeZone.pm that would be distributed with DateTime could be suitably booby-trapped (i.e. warn You must install the full DateTime::TimeZone before using this module). It would be replaced by the full version after DT::TZ was tested and installed. IIUC, that kind of thing causes headaches for those trying to wrap things in an rpm. And some people put *anything* they install into an rpm before installing. Or distribute everything _but_ the generated files and DateTime::TimeZone::OlsonDB. That way you could do offset only and floating time zone stuff, but to do the historical/rules-based stuff you install a separate package. I would also suggest that the base DateTime::TimeZone release only needs to contain stub modules for the data files and the Makefile.PL should actually be responsible for generating the multitude of PM's prior to testing. You could even include a preamble to Makefile.PL which would download the latest Olson file (if you want to make the installation dependent on Net::FTP). For those that don't have Net::FTP installed, the Makefile.PL could request that they independently download the Olson files themselves and expand them into a top level OlsonDB directory and rerun 'perl Makefile.PL' to build the TZ files. 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.
Re: CVS activity
On Fri, 17 Jan 2003 03:44:34 -0600 (CST), [EMAIL PROTECTED] wrote: 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 docs/, which for now just contains my incomplete development-standards.pod document. Sometime this weekend I can make a tarball of what's in there if people are interested. Periodic tarballs would be appreciated.
Re: timezones
On Mon, 13 Jan 2003 13:55:17 -0600 (CST), [EMAIL PROTECTED] wrote: So, this sounds like something very high level, which shouldn't be considered part of the base object. But.. it is needed for really low-level operations, like -add(). For example: 19700328T233000 + 4 hours = ?? You'd think 19700329T033000. And you'd be right most of the time, but not if that time was a Europe/Amsterdam time. Then, it'd be 19700329T043000. The base object will need to _have_ a DateTime::TimeZone object. It will not _be_ one. So, I think we need to either put all of this inside the base object, or make the base object do UTC only. The base object will probably do UTC only for all math and so on, and the internal representation should probably be fixed to UTC. Then the data-returning methods can adjust the returned value based on the timezone object that the base object has. The base object should have the option of not being tied to any particular timezone, even UTC, so that the data-returning methods do no adjustment. For instance, if I take my wife out to dinner at 7PM on our anniversary every year, I do so at that local time whether we are in Seattle or Baltimore. One of the flaws of Date::ICal has been that it has a particular timezone and can't represent this kind of date (pun intended). The iCalendar spec calls this a floating time and differentiates it from a UTC time or a time w/timezone (or a date without a time).
Picking up the ball...or reinventing the wheel?
I need to find more time to read through the flood of messages...but
wanted to mention right away that things look to be going astray.
Apologies if it is not so.
What's the goal here? If it is creating a base class for date/time
modules to standardize on, that won't work. I don't think the authors
of the existing modules are interested. That way only leads to the
creation of Date::Yet::Another::Module.
If it is creating a module to provide some glue between existing
modules, great--but make sure that's the focus. Does that need to be
more complicated than:
$from_object = Date::ICal-new( ical = '19971024T12' );
Date::Glue::-make_a('Date::Calc::Object', $from_object)
where Date::Glue understands the get/set API of as many as possible of
the OO date modules out there?
Another goal I see as worthwhile would be a non-partisan document
comparing the strengths and weaknesses of the existing modules, with a
link to it from the date and time categories on CPAN.
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
On Sat, 11 Jan 2003 16:44:37 -0500 (EST), [EMAIL PROTECTED] wrote: On Sat, 11 Jan 2003, Dave Rolsky wrote: You know, on reflection, I don't think the internals matter _at all_ (well, they need to work, but you already took care of that ;) What matters is that we can return a _standard_ value for the use of other calendar implementers. Yes, that is the conclusion that we came to. Indeed, we changed the internals at least twice, with no change to the API. 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 instead of jd in some places and julian in others. The greg2jd and jd2greg functions should work for any R.D. between minint and maxint inclusive. This gives a range of 11.75+ million years with 32 bit ints and 50 quadrillion years with 64 bit ints. The only other function that really needs to access the internal format is day_of_week. greg2jd is also supposed to return correctly normalized results for any integer values given (e.g. with year -1200, month 1, and day 21, you should get the R.D. 2 billion days after the start of year -1200.). The subs greg2jd and jd2greg and the tests in 09greg.t are are in the public domain. They are based on ideas from the first edition of Calendrical Calculations (especially the Cycles of Years section) but use no actual algorithms from it (which may be under copyright and/or patent protection--though I think Rich Bowen does have an arrangement with the authors for some of his work.) They do resemble the alternate Gregorian functions in the second edition.
Re: Date::Leapsecond
In article [EMAIL PROTECTED], fglock [EMAIL PROTECTED] wrote: SYNOPSIS use Date::Leapsecond; use Time::Local; $epoch_2000 = timegm(0,0,0,1,0,2000 - 1900); $epoch_1990 = timegm(0,0,0,1,0,1990 - 1900); print Seconds between years 1990 and 2000 are ; print Date::Leapsecond::ut1($epoch_2000) - Date::Leapsecond::ut1($epoch_1990); print instead of ; print $epoch_2000 - $epoch_1990; Looks good. How do you handle the future? Right now we only know the actual leap seconds through 2002/12/30. But you could make some kind of prediction for dates beyond that.
Re: alpha/beta $VERSION's
In article [EMAIL PROTECTED], Elaine -HFB- Ashton [EMAIL PROTECTED] wrote: Yitzchak Scott-Thoennes [[EMAIL PROTECTED]] quoth: * *I thought the alpha/beta distinction was only relevant when there was a *earlier GA release (so CPAN.pm doesn't upgrade 1.01 to 1.01_01 or some *such.) Nevertheless, $VERSION should always be a number so that required *version numbers work without extraneous warnings: * *~ $perl -we'use Date::Roman 1.0' *Argument 1.0.1 isn't numeric in subroutine entry at -e line 1. 1.0 is also an invalid version number as it is defined as a floating point number with at least 2 digits following the decimal. The point is that use Module VERSION does a numeric compare, and if $VERSION is a string that isn't numeric, the user gets a warning. Doesn't matter if you say 1, 1.0, 1.00. *Same thing happens with $VERSION=1.00_01 though, and MakeMaker (e.g. *make dist's tarball name) loses the _ if you only say $VERSION=1.00_01; Not with my makemaker...at least not with 5.005_03 or 5.6.1. The _nn has been the semantic for denoting a beta for a long time so MM not dealing with it would be a surprise. Try it: ~/dl/tmp $perl -MExtUtils::MakeMaker -wle'print for $], $ExtUtils::MakeMaker::VERSION' 5.006001 5.45 ~/dl/tmp $tar xfz ../Date-Roman-1.0.1.tar.gz ~/dl/tmp $cd Date-Rom* ~/dl/tmp/Date-Roman-1.0.1 $perl -pi.bak -e's/(\$VERSION =).*/$1 1.00_01/' lib/Date/Roman.pm ~/dl/tmp/Date-Roman-1.0.1 $diff -u0 lib/Date/Roman.pm.bak lib/Date/Roman.pm --- lib/Date/Roman.pm.bak Tue Apr 16 10:53:16 2002 +++ lib/Date/Roman.pm Thu Apr 18 17:18:48 2002 @@ -13 +13 @@ -$VERSION = '1.0.1'; +$VERSION = 1.00_01 ~/dl/tmp/Date-Roman-1.0.1 $perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for Date::Roman ~/dl/tmp/Date-Roman-1.0.1 $make dist [snip] gzip --best Date-Roman-1.0001.tar ^! *Extensive discussion of this problem occured on perl5-porters in Feb *and Mar under subjects '$VERSION problem', 'UNIVERSAL::version objects', *and 'Argument 1.23_45 isn't numeric in subroutine entry'. This is a different problem and isn't terribly critical since it's for alpha/beta modules and shouldn't keep people from using version numbers properly. Properly includes alpha/beta modules. These should have a string $VERSION= line with the underscore for MakeMaker/CPAN. $XS_VERSION must also match what MakeMaker sees for bootstrap's version check. And $VERSION must be numeric for use Module VERSION syntax to work. Much of CPAN is bereft of version numbers or valid numbers at all so I don't think it's a real sticking point. I agree that using VERSION at all is good. But we might as well tell folks how to do it right. For now, for alpha/beta versions that means: $VERSION = 1.12_01; $XS_VERSION = $VERSION; # only needed if you have XS code $VERSION = eval $VERSION;
