local timezone
Hello!
I have a problem with DateTime::set_time_zone(local) call: it says that
cannot determine local timezone. Actually, this behavior appeared when I
upgraded DateTime modules (and relatves). After little investigation I found
that since v0.12 (that I used before) there was changed local timezone
determination algorithm and, the following lines are disappeared:
my @t = gmtime;
my $local = Time::Local::timelocal(@t);
my $gm= Time::Local::timegm(@t);
return
DateTime::TimeZone::OffsetOnly-new
( offset = offset_as_string( $gm - $local ) );
What was the reason of cutting off that method? Yes, there are several new
methods of local timezone determination appeared, but all of them applicable
only under UNIX systems. Unfortunately, my script should work under Windows
and, therefore, I have lost a chance to determine local timezone. The only
way left under Windows is to use environment variable, but this method
scarcely applicable for me too: the script will be used by customer and I
can't guarantee that TZ variable always will be set properly. For the
moment, I used a hack - I added several strings to
DateTime::TimeZone::Local:
sub local_time_zone
{
my $tz;
foreach ( qw( _from_env _from_etc_localtime _from_etc_timezone
_from_etc_sysconfig_clock _old_plain) )
{
$tz = __PACKAGE__-$_();
return $tz if $tz;
}
die Cannot determine local time zone\n;
}
sub _old_plain
{
my @t = gmtime;
my $local = Time::Local::timelocal(@t);
my $gm= Time::Local::timegm(@t);
return
DateTime::TimeZone::OffsetOnly-new
( offset = DateTime::TimeZone::offset_as_string( $gm - $local )
);
}
Could anybody suggest a more suitable way? Or, maybe, just add something
like I wrote above into DateTime::TimeZone::Local?
Best regards, Elliot.
---
Ilya A. Tereshchenko
Developer
Aurorisoft Inc.
E-mail: [EMAIL PROTECTED]
For more visit http://www.aurorisoft.com/ http://www.novosoft-usa.com/
---
Re: patch to DT::F::Builder
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.
Got it. I think this diff would do. Thanks for the pointer :)
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.36
diff -d -u -r1.36 Builder.pm
--- lib/DateTime/Format/Builder.pm 30 Jan 2004 07:09:13 - 1.36
+++ lib/DateTime/Format/Builder.pm 4 Feb 2004 09:07:14 -
@@ -14,7 +14,7 @@
use Params::Validate qw(
validate SCALAR ARRAYREF HASHREF SCALARREF CODEREF GLOB GLOBREF UNDEF
);
-use vars qw( $VERSION %dispatch_data );
+use vars qw( $VERSION %dispatch_data @CARP_NOT );
my $parser = 'DateTime::Format::Builder::Parser';
$VERSION = '0.7801';
@@ -201,13 +201,8 @@
{
my ($class, $input) = @_;
-my $pkg;
-my $i = 0;
-while (($pkg) = caller($i++)) {
-last if (!UNIVERSAL::isa($pkg, 'DateTime::Format::Builder')
-!UNIVERSAL::isa($pkg, 'DateTime::Format::Builder::Parser'));
-}
-local $Carp::CarpLevel = $i;
+local @CARP_NOT =
+qw(DateTime::Format::Builder DateTime::Format::Builder::Parser);
croak Invalid date format: $input;
}
Cannot Install DateTime For ActivePerl Under Windows XP
I'm trying to install DateTime-0.1901 for ActivePerl under Microsoft Windows XP. I don't have a C compiler (but I don't need one, right?). I successfully installed DateTime-TimeZone-0.2506 and DateTime-Locale-0.07. Basically, *none* of the DateTime.pm tests are succeeding. C:\DateTime\DateTime-0.1901perl Makefile.PL Testing if you have a C compiler Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. cl /c test.c 'cl' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1' Stop. I cannot determine if you have a C compiler so I will install a perl-only implementation You can force installation of the XS version with perl Makefile.PL --xs Warning: prerequisite Pod::Man 1.14 not found. Writing Makefile for DateTime C:\DateTime\DateTime-0.1901nmake Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. C:\DateTime\DateTime-0.1901nmake test ... BEGIN failed--compilation aborted at C:\DateTime\DateTime-0.1901\blib\lib/DateTi me.pm line 43. Compilation failed in require at t\28dow.t line 7. BEGIN failed--compilation aborted at t\28dow.t line 7. t\28dow.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-1112 Failed 1112/1112 tests, 0.00% okay t\99-podok 1/1 skipped: File::Find::Rule not installed Failed TestStat Wstat Total Fail Failed List of Failed --- t\00load.t1 256 11 100.00% 1 t\01sanity.t255 6528016 16 100.00% 1-16 t\02last_day.t 255 6528073 73 100.00% 1-73 t\03components.t255 65280 122 122 100.00% 1-122 t\04epoch.t 255 6528032 32 100.00% 1-32 t\05set.t 255 6528027 27 100.00% 1-27 t\06add.t 255 65280 534 534 100.00% 1-534 t\07compare.t 255 6528026 26 100.00% 1-26 t\09greg.t 255 6528035 35 100.00% 1-35 t\10subtract.t 255 6528096 96 100.00% 1-96 t\11duration.t 255 6528086 86 100.00% 1-86 t\12week.t 255 6528026 26 100.00% 1-26 t\13strftime.t 255 65280 132 132 100.00% 1-132 t\14locale.t255 65280 88 100.00% 1-8 t\15jd.t255 6528016 16 100.00% 1-16 t\16truncate.t 255 6528040 40 100.00% 1-40 t\17set_return.t255 65280 77 100.00% 1-7 t\18today.t 255 65280 66 100.00% 1-6 t\19leap_second.t 255 6528071 71 100.00% 1-71 t\20infinite.t 255 65280?? ?? % ?? t\21bad_params.t255 6528025 25 100.00% 1-25 t\22from_doy.t 255 6528098 98 100.00% 1-98 t\23storable.t 255 65280?? ?? % ?? t\24from_object.t 255 65280 88 100.00% 1-8 t\25add_subtract.t 255 6528010 10 100.00% 1-10 t\26dt_leapsecond_pm.t 255 65280 99 100.00% 1-9 t\27delta.t 255 6528038 38 100.00% 1-38 t\28dow.t 255 65280 1112 1112 100.00% 1-1112 1 subtest skipped. Failed 28/29 test scripts, 3.45% okay. 2654/2655 subtests failed, 0.04% okay. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0xff' Stop. C:\DateTime\DateTime-0.1901 I installed (nmake install) anyway and this is what I get when I try to use DateTime: C:\DateTime\DateTime-0.1901perl -MDateTime -e 1 Can't locate loadable object for module DateTime in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .) at C:/Perl/lib/XSLoader.pm line 43 BEGIN failed--compilation aborted at C:/Perl/site/lib/DateTime.pm line 43. Compilation failed in require. BEGIN failed--compilation aborted. C:\DateTime\DateTime-0.1901 I feel like I'm so close! I'm frustrated, though. Could *this* possibly be the problem? Warning: prerequisite Pod::Man 1.14 not found. Actually, I do have Pod::Man installed! # Pod::Man -- Convert POD data to formatted *roff input. # $Id: Man.pm,v 1.34 2002/07/15 05:46:00 eagle Exp $ Any ideas? -- Jim Monty [EMAIL PROTECTED]
Re: local timezone
On Wed, 4 Feb 2004, Ilya A. Tereshchenko wrote: my @t = gmtime; my $local = Time::Local::timelocal(@t); my $gm= Time::Local::timegm(@t); return DateTime::TimeZone::OffsetOnly-new ( offset = offset_as_string( $gm - $local ) ); What was the reason of cutting off that method? Yes, there are several new The problem with this is that it doesn't really get a valid timezone, but instead gets the current offset from UTC. If this code runs in a timezone that has daylight saving changes, then it will not be all that accurate. All the new methods for determining the local time zone are more likely to get something useful like Europe/Paris, which is a real time zone. only under UNIX systems. Unfortunately, my script should work under Windows and, therefore, I have lost a chance to determine local timezone. The only way left under Windows is to use environment variable, but this method scarcely applicable for me too: the script will be used by customer and I can't guarantee that TZ variable always will be set properly. For the I know that Windows stores a real time zone _somewhere_, and there's got to be a way to get that information. A patch to do so would be welcome. Even better would be a patch with tests that are known to pass on Win32. But the old get the current offset approach really was fundamentally broken, and I'm not willing to put it back in. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Pondering about DT::F::Japanese
So now I'm pondering on Ricks' suggestion that I should make DT::F::Japanese behave more like (strp|strf)time. This is mainly me talking to myself, but please pitch in if you have any ideas (especially if you speak/read/write Japanese -- I know you guys are out there) First, I need to enumerate the possible formats: - General Number Representation: - roman (ascii) - double-byte roman - double-byte kanji - Year Representation - by gregorian - by gregorian, with gregorian marker - by gregorian, with A.C./B.C. marker - by Japanese era (mutually exclusive with the above three) - Month representation - month-number followed by month kanji - traditional month names (to be implemented with DT::F::J::Traditional) - Time - Am/Pm - modern notation - traditional notation (to be implemented with DT::F::J::Traditional) - Miscellaneous - Day of week - There's this thing that assigns names to each date in cycle of 6 days, which I may or may not add (requires traditional calendar) My main concerns in trying to encode this into a (strp|strf)time-ish format are as follows: - Encoding is actually a combination of number representation and whatever else format. for example, the era notation is actually 1) era/roman 2) era/double-byte roman 3) era/kanji. - I personally think that the encoding scheme for (strp|strf)time is horrendous in some cases -- %[a-zA-Z] is just confusing sometimes -- it certainly doesn't make it easier for the Japanese audience - I'm already jumping through hoops trying to write regexps that match unicode Japanese. Will this add even more to the pain? Hmmm, I guess I'm just having a hard time trying to picture what it is that I gain while I feel that I lose a lot of the ease of use and maintainability by adding this (strp|strf)time-ish generalization on the formatting. But I may be wrong. Please let me know if you have any comments on this. --d
A Time-only namespace?
I'd like to rip out the traditional Japanese time support from DT::C::Japanese and place it on its own module, so that a) I can use it for Gregorian-based calendars and b) I can test it more thoroughly (presumably it will be much faster, because I wouldn't have to worry about calculating lunar/solar longitudes every time I want to test it :) Now I noticed there isn't a namespace for this under DateTime. Is there any namespace that is recommended? I guess it may not make sense to put it under DateTime::, so would something like Time::Japanese work? --d
Re: A Time-only namespace?
Daisuke Maki wrote: Now I noticed there isn't a namespace for this under DateTime. Is there any namespace that is recommended? I guess it may not make sense to put it under DateTime::, so would something like Time::Japanese work? I've always thought there should be support and functionality for 'clocks' (DateTime::Clock::*) that do not have to be connected to a calendar. I think the only thing that approaches this at the moment is DateTime::Incomplete. Matt
Re: Pondering about DT::F::Japanese
On Wed, 4 Feb 2004, Daisuke Maki wrote: My main concerns in trying to encode this into a (strp|strf)time-ish format are as follows: - Encoding is actually a combination of number representation and whatever else format. for example, the era notation is actually 1) era/roman 2) era/double-byte roman 3) era/kanji. - I personally think that the encoding scheme for (strp|strf)time is horrendous in some cases -- %[a-zA-Z] is just confusing sometimes -- it certainly doesn't make it easier for the Japanese audience - I'm already jumping through hoops trying to write regexps that match unicode Japanese. Will this add even more to the pain? Hmmm, I guess I'm just having a hard time trying to picture what it is that I gain while I feel that I lose a lot of the ease of use and maintainability by adding this (strp|strf)time-ish generalization on the formatting. But I may be wrong. Please let me know if you have any comments on this. I don't know that all possible sets of formatted outputs really lend themselves well to strftime notation, and I don't think you should feel obligated to come up with one here. At the very least, I think the existing interface to DT::F::Japanese should continue to exist. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
