Re: Olson - Microsoft mappings
Josh, My deepest apologies for misunderstanding the Alias modules both times I read it over. You are totally correct in that Alias is very similar to what I'm looking for and that like what Ben suggested of using submodules of Alias I can get what I'm after. UI for end user selection would probably be a great topic for an article to go on datetime.perl.org - however that's off topic from this discussion. And it's off topic for this list. :) I disagree. The question of How do I get my end users to choose their timezone using the DateTime modules is a very relevant discussion because it's part of a complete application. If I made a world clock app and the only way for you to choose the timezone was to look through a list of 364 alphabetized Olson names (perhaps broken into 9 categories) you'd throw it away and use something more friendly (at least I'd hope you would ;) ). For instance, So what's the time in Ireland? Do you use Europe/Dublin or Europe/Belfast? What's the difference? Do you expect the end user to know that Dublin and Belfast are in Ireland before they can see the time in Ireland? Or another example, where the heck is Europe/Chisinau in the world and is this something I need to see right now? All the America/Kentucky, America/Indiana amd America/Boise entries are completely superfluous in a current world and confuse people (perhaps it's just my people, but I still had to deal with them). I'm sure there are others in the database but the US is what I'm most familiar with at the moment. So you want to throw out functionality just because you don't have a use for it? Throw it out from my particular application yes. Throw it out of DT absolutely not. I'm not even trying to throw it out, I'm just trying to remove the end users ability to see it because it's confusing them and they don't need it. I gaurantee you there are not 364 timezone/DST rules in use in the world today. The 364 zones are only needed if you are using dates in the past, which I'm not. Future timezone changes are a different story altogether. So you want to throw out backwards compatibility too? What are you going to do when a time zone changes rules and happens to coincide with another? If the UTC offset and DST rules coincide (aka they are the same zone) and there is no significant advantage to having it (for instance they are in different countries), then I'm going to only present the one most easily recoginizable one to people from that locale. I'm not intending to remove anything from the recognized list of zone names so any prior stored references to the now removed zone name would still work, the UI will just stop presenting that as an option for end users to select. For instance, the UI will only present ~6 time zones for the continental United States not 16 and if some reference to any of the other 10 still existed and the application was asked to use it, it would still work. My purpose is to make the end user's experience of finding their timezone easier and to give programmers peace of mind in programitcally building a UI for selecting a zone. I'd love to use something like what Ben suggested which grouped the zone names into their respective countries since that would get updated with any module upgrades. Going forward I'd like to focus on actually making Ben's suggestion a reality. I'd like to add that timezones should also have a description which could be presented to the end user to help describe the time zone in more detail. -- Michael --
Re: Olson - Microsoft mappings
Joshua == Joshua Hoblitt [EMAIL PROTECTED] writes: Joshua You have incorrectly attributed that comment to me. No, he had two chevrons in front of the text. This correctly attributes it as something you quoted. Although, it'd be nice if everyone used Emacs supercite instead of chevrons. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Re: Olson - Microsoft mappings
Michael Fair [EMAIL PROTECTED] wrote:
For instance, So what's the time in Ireland?
Do you use Europe/Dublin or
Europe/Belfast? What's the
difference?
Do you expect the end user to know that
Dublin and Belfast are in
Ireland
before they can see the time in Ireland?
This is a bit of a beef I have (as of earlier
today) with the Olson project. I've managed
to auto-map about 174 of the olson zones to
geographic places but am scared I may have to
do the rest by hand. I wish the names were
more along the lines of:
Oceania/Australia/Melbourne-Victoria
Rather than
Australia/Melbourne
Once I've completed my research we should have:
$time_zone{$continent}{$country}{$region} and/or
$time_zone{$continent}{$country}{$city}
I figure we should allow access to the data
such that we can get a list that looks like:
Oceania
- Australia
- Melbourne (Victoria)
It would probably be good to create
DateTime::TimeZone::Select to hold this data,
and then DateTime::TimeZone::Select::HTML and
DateTime::TimeZone::Select::Tk and
DateTime::TimeZone::Select::Terminal for
holding widgets for people to just drop in place.
DateTime::Event::Sunset problems
I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module, but I'm having a problem. Below is my test code. The results from the code are: 2003-09-24T10:42:00 2003-09-24T22:48:00 Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing wrong? Steve W. #!/usr/local/bin/perl use DateTime; use DateTime::Event::Sunrise; my $dt = DateTime-new( year = 2003, month = 9, day= 24, time_zone = 'America/New_York', ); my $sunrise = DateTime::Event::Sunrise-sunrise ( longitude ='-73.59', latitude ='40.38', altitude = '-0.833', iteration = '1' ); my $sunset = DateTime::Event::Sunrise-sunset ( longitude ='-73.59', latitude ='40.38', altitude = '-0.833', iteration = '1' ); my $rise = $sunrise-next($dt); print $rise-datetime, \n; my $set = $sunset-next($dt); print $set-datetime, \n;
Re: DateTime::Event::Sunset problems
Steven J. Weinberger wrote: I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module, but I'm having a problem. Below is my test code. The results from the code are: 2003-09-24T10:42:00 2003-09-24T22:48:00 Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing wrong? I think these results are in UTC time. - Flavio S. Glock
Re: Re: Olson - Microsoft mappings
On Wed, 24 Sep 2003 [EMAIL PROTECTED] wrote:
This is a bit of a beef I have (as of earlier
today) with the Olson project. I've managed
to auto-map about 174 of the olson zones to
geographic places but am scared I may have to
do the rest by hand. I wish the names were
more along the lines of:
Oceania/Australia/Melbourne-Victoria
Rather than
Australia/Melbourne
Once I've completed my research we should have:
$time_zone{$continent}{$country}{$region} and/or
$time_zone{$continent}{$country}{$city}
You do realize that mapping time zones to countries will take a _lot_ of
maintenance, right?
Countries are changing all the time. Think back to the end of the cold
war, when the USSR dissolved, along with Yugoslavio and Czechoslovakia,
and at the same time E W Germany became a single country.
And how do you handle things like Taiwan Hong Kong? Are they separate
countries? Hong Kong was once sort of a separate country, but is now
clearly part of China. Is Taiwan part of China? Depends who you ask ;)
My wife is Taiwanese and I sure as hell think they're separate countries,
but ask many mainlanders and you'll get a different answer.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Event::Sunset problems
On Wed, 24 Sep 2003, Flavio S. Glock wrote: Steven J. Weinberger wrote: I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module, but I'm having a problem. Below is my test code. The results from the code are: 2003-09-24T10:42:00 2003-09-24T22:48:00 Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing wrong? I think these results are in UTC time. Hmm, this should probably be changed so that the returned object has the same time_zone as was passed to next(). I think this change would go in DT::E::Sunrise. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Event::Sunset problems
Dave Rolsky wrote: On Wed, 24 Sep 2003, Flavio S. Glock wrote: Steven J. Weinberger wrote: Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing wrong? I think these results are in UTC time. Hmm, this should probably be changed so that the returned object has the same time_zone as was passed to next(). I think this change would go in DT::E::Sunrise. You can use (untested): $sunset = DateTime::Event::Sunrise( %param )-set_time_zone( $my_time_zone ); - Flavio S. Glock
Re: Olson - Microsoft mappings
Dave Rolsky wrote: You do realize that mapping time zones to countries will take a _lot_ of maintenance, right? Countries are changing all the time. Think back to the end of the cold war, when the USSR dissolved, along with Yugoslavio and Czechoslovakia, and at the same time E W Germany became a single country. While this is true, it is also true that there are many countries that are *not* changing all of the time. Users in these countries might prefer a more intuitive UI for timezone selection rather than the pedantically correct bulk Olson listings. Put another way, if we can find a way to programatically categorize say 50% of the Olson DB, this still has value -- correct, it does not automatically digest the entire Olson DB, but if it captures 90% of the timezones in common usage then this effort still has value. Matt
Re: DateTime::Event::Sunset problems
Steven J. Weinberger wrote: Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing wrong? I think these results are in UTC time. Hmm, this should probably be changed so that the returned object has the same time_zone as was passed to next(). I think this change would go in DT::E::Sunrise. You can use (untested): $sunset = DateTime::Event::Sunrise( %param )-set_time_zone( $my_time_zone ); Doesn't work. I'm looking for the bug... - Flavio S. Glock
Re: DateTime::Event::Sunset problems
Flavio S. Glock wrote: Steven J. Weinberger wrote: Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing wrong? I think these results are in UTC time. Hmm, this should probably be changed so that the returned object has the same time_zone as was passed to next(). I think this change would go in DT::E::Sunrise. You can use (untested): $sunset = DateTime::Event::Sunrise( %param )-set_time_zone( $my_time_zone ); Doesn't work. I'm looking for the bug... Fixed in CVS. It was a bug in DateTime::Set - Flavio S. Glock
Re: Re: Olson - Microsoft mappings
On Wed, Sep 24, 2003 at 10:54:04AM -0500, Dave Rolsky said: You do realize that mapping time zones to countries will take a _lot_ of maintenance, right? Just as a FWIW ... http://blogs.gotdotnet.com/raymondc/PermaLink.aspx/8b23d26b-7e11-425d-b612-13396ef3ec71
ANNOUNCE: DateTime-Set 0.1202
DateTime-Set 0.1202 - bug fix: when asking for next after a set_time_zone or add_duration. example: $recurr-add_duration($dur)-next($dt) returns: $recurr-next($dt) - Flavio S. Glock
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: DateTime::Event::Sunset problems
On Wed, 24 Sep 2003, Flavio S. Glock wrote: This is what it looks like (tested!): --- #!/usr/local/bin/perl use DateTime; use DateTime::Set 0.1202; use DateTime::Event::Sunrise; my $dt = DateTime-new( year = 2003, month = 9, day= 24, time_zone = 'America/New_York', ); my $sunrise = DateTime::Event::Sunrise-sunrise ( longitude ='-73.59', latitude ='40.38', altitude = '-0.833', iteration = '1' )-set_time_zone( 'America/New_York' ); I really don't think we should make users do this if we can avoid. my $rise = $sunrise-next($dt); print $rise-datetime, , $rise-time_zone_long_name, \n; This should probably set the returned datetime to the same timezone as the given datetime. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Event::Sunset problems
Dave Rolsky wrote:
On Wed, 24 Sep 2003, Flavio S. Glock wrote:
my $sunrise = DateTime::Event::Sunrise-sunrise (
longitude ='-73.59',
latitude ='40.38',
altitude = '-0.833',
iteration = '1'
)-set_time_zone( 'America/New_York' );
I really don't think we should make users do this if we can avoid.
my $rise = $sunrise-next($dt);
print $rise-datetime, , $rise-time_zone_long_name, \n;
This should probably set the returned datetime to the same timezone as the
given datetime.
How about this?
sub _following_sunrise {
[ ... initialize ...]
my $tz = $dt-time_zone;
my $loc = $dt-locale;
[ ... some calculations ... ]
$tmp_rise-set_time_zone( $tz ); # unless $tz-is_floating ???
$tmp_rise-set_locale( $loc );
return $tmp_rise;
}
- Flavio S. Glock
Re: DateTime::Event::Sunset problems
Dave Rolsky wrote:
On Wed, 24 Sep 2003, Flavio S. Glock wrote:
sub _following_sunrise {
[ ... initialize ...]
my $tz = $dt-time_zone;
my $loc = $dt-locale;
[ ... some calculations ... ]
$tmp_rise-set_time_zone( $tz ); # unless $tz-is_floating ???
$tmp_rise-set_locale( $loc );
return $tmp_rise;
}
It's probably ok to set the time zone even if the given DT is in the
floating time zone.
No, converting from UTC to floating would give the same unexpected
results.
How about adding ( localtime - gmtime ) before converting to floating?
- Flavio S. Glock
Install Problem with DateTime.pm
I'm stumped.. I have a problem installing DateTime.pm. I get a LNK1106 U1077 with the 'nmake' command. The messages for PERL- V and 'nmake' are below. I am using Windows XP and VC++ 5 I have plenty of available space on my hard drive and there are no integrity problems. I have searched google and found some references to upgrading to VC++ 6 would solve the problem, but before I spend the cash, I would like some conformation of that. Has anyone encountered this problem before? Got a solution? ---PERL -V messages below Summary of my perl5 (revision 5 version 6 subversion 1) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX', optimize='-O1 -MD -DNDEBUG', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -release -libpath:D:/Perl\lib\CORE -machine:x86' libpth=c:\program files\devstudio\vc\lib c:\program files\devstudio\vc\mfc\lib %lib% D:\Perl\lib\CORE libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -libpath:D:/Perl\lib\CORE -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 633 Built under MSWin32 Compiled at Jun 17 2002 21:33:05 @INC: D:/Perl/lib D:/Perl/site/lib . -nmake messages below Microsoft (R) Program Maintenance Utility Version 1.62.7022 Copyright (C) Microsoft Corp 1988-1997. All rights reserved. link -out:blib\arch\auto\DateTime\DateTime.dll -dll -nologo -nodefaultlib -release -libpath:D:/Perl\lib\CORE -machine:x86 DateTime.obj D:\Perl\lib\CORE\perl56.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib -def:DateTime.def D:\Perl\lib\CORE\perl56.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x3d11dddc NMAKE : fatal error U1077: 'link' : return code '0xc' Stop.
