RFC: DateTime::Event::Basic
DateTime::Event::Basic - A base class for building Event classes. - Provides generic things like new( event = 'type', %param ) as_set( span = $span ) as_list( span = $span ) is( datetime = $dt ) closest( datetime = $dt ) event parameter specify a subtype, like western, eastern, sunrise and sunset. %parm specify longitude, latitude, ... - Other classes will override these: initialize( event = 'type', %param ); next( datetime = $dt ); - Synopsis: $dt_ev1 = new DT::Ev::Whatever( event = 'western', %param ); $dt_ev1 = new DT::Ev::Whatever( event = 'eastern', %param ); $same_day = $dt_ev1-as_set-intersection( $dt_ev2-as_set ); Besides, this class could provide basic events, like day, year. - Flavio S. Glock
Re: RFC: DateTime::Event::Basic
Flavio S. Glock wrote: as_list( span = $span ) is( datetime = $dt ) Syntax sugar - these could be project wide: Whenever a span is required, accept start/end/after/before parameters too. Whenever a datetime is required, accept year/month/day/hour/minute/second parameters too. Whenever a duration is required, accept months/days/hours/minutes/seconds parameters too. - Flavio S. Glock
RE: Bundle::DateTime
Hi Iain, [snipped] * Rick Measham ([EMAIL PROTECTED]) [03 Apr 2003 09:22]: [...] Ages ago I proposed that we might need to distribute Bundle::DateTime and now I'm thinking it again. Either that or we could think about auto-install (which I think DBI does?) It may also be useful if someone who uses Windows, and knows how to do it, could produce PPMs and a PAR. I may be able to help out here. I currently have 2 version of perl (5.6.1 5.8.0) on my W2K box. along with visual studio 6.0 It has been a while since I have created a PPM but I'm sure I could pick it up again. As for PAR I have never worked with it so I can't say. Just let me know!! Ron Hill
Re: ICal date-time spec
Matthew Buckett wrote: For the strings that are used to create new Date::ICal instances (eg Date::ICal-new( ical = '19971024T12' ); ) does this module follow a spec from somewhere else? There is the Date-Time section (4.3.5) from RFC2445 http://www.ietf.org/rfc/rfc2445.txt which gives a formal spec for the date-time format. It seems like Date::ICal impliments a relaxed version of this Date-Time and a bit of Date. Am I looking in the right place? Yes, it is based on RFC2445. Date::ICal does not implement named timezones. If you need additional functionality, that would be in the new DateTime module, or in Net::ICal. Net::ICal - Interface to RFC2445 (iCalendar) calendaring and scheduling protocol. DateTime - Reference implementation for Perl DateTime objects - Flavio S. Glock
Re: ICal date-time spec
Matthew Buckett wrote: If I attempt to parse the ICal date 20030403 I get the DateTime of 20030402T23Z due to currently being in british summer time. To get around this I can append a Z to the Date to give 20030403Z put this is not a legal Date accoring to RFC2445. Does DateTime behaves correctly? | Net::ICal - Interface to RFC2445 (iCalendar) calendaring and | scheduling protocol. This is the module that I am looking at and the last CVS commits made seem to hint that Date::ICal should be used instead of Net::ICal::Time | DateTime - Reference implementation for Perl DateTime objects Maybe I should look at changing Net::ICal to use DateTime::Format::ICal? I am (more-or-less) maintaining Date::ICal. We could work on a fix for it, and making it use DateTime::Format::ICal would be a good choice. Net::ICal should behave correctly after that. The latest development version of Date::ICal is here: http://www.ipct.pucrs.br/flavio/perl/Date-ICal-2.07.tar.gz - Flavio S. Glock
Params::Validate generate warnings on perl version 5.8.0
Hi Dave,
I am seeing warnings when building some Datetime perl modules
under 5.8.0. They were not there for version 5.6.1.
Can I ignor them?
Thanks
Ron Hill
for perl version 5.8.0
F:\perl_modules\Params-Validate-0.57perl makefile.pl
Checking if your kit is complete...
Looks good
Writing Makefile for Params::Validate
[snipped]
F:\perl_modules\Params-Validate-0.57nmake
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
[more snippage]
cl -c-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE
-DNO_STRICT -DHAVE_DES_FCRYPT -
DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-DPERL_MSVCRT_READFIX -MD -DNDEBUG -O1-D
VERSION=\0.57\ -DXS_VERSION=\0.57\ -IF:\Perl\lib\CORE Validate.c
Validate.c
Validate.xs(631) : warning C4101: 'he' : unreferenced local variable
Validate.xs(706) : warning C4018: '' : signed/unsigned mismatch
Validate.xs(821) : warning C4101: 'value' : unreferenced local variable
Validate.xs(948) : warning C4101: 'max' : unreferenced local variable
Validate.xs(949) : warning C4101: 'limit' : unreferenced local variable
[snippage]
then I switched to perl version 5.6.1
F:\perl_modules\Params-Validate-0.57nmake distclean
[snipped]
F:\perl_modules\Params-Validate-0.57perl makefile.pl
[more snippage]
F:\perl_modules\Params-Validate-0.57nmake
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
cp lib/Params/ValidatePP.pm blib\lib\Params\ValidatePP.pm
cp lib/Attribute/Params/Validate.pm blib\lib\Attribute\Params\Validate.pm
cp lib/Params/ValidateXS.pm blib\lib\Params\ValidateXS.pm
cp lib/Params/Validate.pm blib\lib\Params\Validate.pm
F:\perl\bin\Perl.exe -IF:\Perl\lib -IF:\Perl\lib
F:\Perl\lib\ExtUtils/xsubpp -typemap F:\Pe
rl\lib\ExtUtils\typemap Validate.xs Validate.xsc F:\perl\bin\Perl.exe
-IF:\Perl\lib -IF:\Perl\l
ib -MExtUtils::Command -e mv Validate.xsc Validate.c
cl -c -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
-DHAVE_DES_FCRYPT -DPERL_IMPL
ICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX -O1 -MD -DNDEBUG
-DVERSION=\0.57\ -DXS_
VERSION=\0.57\ -IF:\Perl\lib\CORE Validate.c
Validate.c
Running Mkbootstrap for Params::Validate ()
F:\perl\bin\Perl.exe -IF:\Perl\lib -IF:\Perl\lib -MExtUtils::Command
-e chmod 644 Validate.b
s
F:\perl\bin\Perl.exe -IF:\Perl\lib -IF:\Perl\lib
-MExtUtils::Mksymlists -e Mksymlists(
'NAME' = 'Params::Validate', 'DLBASE' = 'Validate', 'DL_FUNCS' = { },
'FUNCLIST' = [], 'IMPORTS
' = { }, 'DL_VARS' = []);
link -out:blib\arch\auto\Params\Validate\Validate.dll -dll -nologo
-nodefaultlib -release -
libpath:F:\Perl\lib\CORE -machine:x86 Validate.obj
F:\Perl\lib\CORE\perl56.lib oldnames.lib ker
nel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib
shell32.lib ole32.lib oleaut3
2.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib msvc
rt.lib -def:Validate.def
Creating library blib\arch\auto\Params\Validate\Validate.lib and object
blib\arch\auto\Params\Val
idate\Validate.exp
F:\perl\bin\Perl.exe -IF:\Perl\lib -IF:\Perl\lib -MExtUtils::Command
-e chmod 755 blib\arch\
auto\Params\Validate\Validate.dll
F:\perl\bin\Perl.exe -IF:\Perl\lib -IF:\Perl\lib -MExtUtils::Command
-e cp Validate.bs blib\
arch\auto\Params\Validate\Validate.bs
F:\perl\bin\Perl.exe -IF:\Perl\lib -IF:\Perl\lib -MExtUtils::Command
-e chmod 644 blib\arch\
auto\Params\Validate\Validate.bs
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Wed, 2 Apr 2003, Joshua Hoblitt wrote: - should it have a clone method? Only if it has methods that can change the internal object state after it's created, like DateTime.pm's set(), set_time_zone(), etc. - when from_object is used should the value for seconds returned by utc_rd_values be stored then returned by the object itself? This would allow chaining of calendars without a loss of precision. Yes, please do so. I will add this to the calendar development docs. - what other methods would be useful? Offhand, -set(), -add(), -subtract(), accessors for each component (baktun, katun, etc.) - can I have some suggestions for tests? The tests you have so far look fine. As you add more methods, add more tests ;) Why does from_object take a language parameter? Cut and paste-o? It's not being used internally. Also, according to Abigail's Data::Maya module, there are three possible Mayan epochs. Maybe this should be changeable on a per-object basis. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: Params::Validate generate warnings on perl version 5.8.0
On Thu, 3 Apr 2003, Hill, Ronald wrote: I am seeing warnings when building some Datetime perl modules under 5.8.0. They were not there for version 5.6.1. Can I ignor them? Do the tests pass? Yes, all tests pass :-) I did not think this would be a problem but I thought you would like to know. Ron Hill
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Joshua Hoblitt schreef: - when from_object is used should the value for seconds returned by utc_rd_values be stored then returned by the object itself? This would allow chaining of calendars without a loss of precision. Best would probably be te either use Mayan time (if it is known (probably not)), or to implement 'our' time (complete with timezones etc.). The last option can be done very easily by including the line: use DateTime::Time; (as soon as I have written that module, of course...) This would also solve the following problem: $d = DateTime-new( year = 2003, month = 4, day= 3, hour = 0,minute = 0, second = 0 ); $md = DateTime::Calendar::Mayan-from_object( object = $d ); print $md-date, \n; # prints 12,19,10,2,10 $d = DateTime-new( year = 2003, month = 4, day = 3, hour = 0,minute = 0, second = 0, time_zone = 'Europe/Amsterdam' ); $md = DateTime::Calendar::Mayan-from_object( object = $d ); print $md-date, \n; # prints 12,19,10,2,9 Some other things I noticed: Baktun's are numbered 13, 1, 2, 3, ..., 12 (and repeat). Yours are numbered -inf, ..., -2, -1, 0, 1, 2, ..., +inf, so the module will only give the correct long count from about 2700BC to about 2400AD. You may want to add a 'cycle' count (1 cycle = 13 baktuns). Also, the default value for baktun should perhaps be 13. You use a comma as default separator for the long count. On the web, I've only found periods. Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
- what other methods would be useful? Offhand, -set(), -add(), -subtract(), accessors for each component (baktun, katun, etc.) -set_baktun or -set( baktun = ... ) ? Should DT::Duration objects be supported? Why does from_object take a language parameter? Cut and paste-o? It's not being used internally. I was thinking that there might be some Mayan glyphs in UTF8. :) Also, according to Abigail's Data::Maya module, there are three possible Mayan epochs. Maybe this should be changeable on a per-object basis. I haven't looked at her module (but I will now that I know it exists). The epoch is already separated out for easy changes. I was thinking of a -set_epoch() that can select from built-ins or accept an epoch in rd. Cheers, -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, Apr 03, 2003 at 10:11:24AM -1000, Joshua Hoblitt wrote: Some other things I noticed: Baktun's are numbered 13, 1, 2, 3, ..., 12 (and repeat). Yours are numbered -inf, ..., -2, -1, 0, 1, 2, ..., +inf, so the module will only give the correct long count from about 2700BC to about 2400AD. You may want to add a 'cycle' count (1 cycle = 13 baktuns). Also, the default value for baktun should perhaps be 13. The easiest thing to do would be to catch that stuff in the constructor. However I had assumed that a baktun could be 0-20 as 1 pictun = 20 baktun. Do you have source of documentation you could point me at? The calendar FAQ. Abigail
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Joshua Hoblitt schreef: This would also solve the following problem: $d = DateTime-new( year = 2003, month = 4, day= 3, hour = 0,minute = 0, second = 0 ); $md = DateTime::Calendar::Mayan-from_object( object = $d ); print $md-date, \n; # prints 12,19,10,2,10 $d = DateTime-new( year = 2003, month = 4, day = 3, hour = 0,minute = 0, second = 0, time_zone = 'Europe/Amsterdam' ); $md = DateTime::Calendar::Mayan-from_object( object = $d ); print $md-date, \n; # prints 12,19,10,2,9 I think thats correct behavior isn't it? The value for RD utc passed will be different because the top example is a floating time. It's correct behaviour, for some values of correct. But it is unexpected that 2003-04-03 is converted into 12,19,10,2,9, only because of the timezone. An even worse example: how do you print today's date? Wrong answer #1: print DateTime::Calendar::Mayan-now-date; This prints the Mayan date corresponding to the UTC date, which can be different from the local date. (Which can't be helped, as the local timezone isn't mentioned.) Wrong answer #2: print DateTime::Calendar::Mayan-from_object( object = DateTime-now(time_zone = 'Europe/Amsterdam') ); (assuming that now() accepts a timezone. if it doesn't, replace the DateTime object by DateTime-now-set_time_zone( 'Europe/Amsterdam' )) Because DT::C::Mayan converts from UTC, and does not keep the timezone info, this has the same result as answer #1. Correct answer: print DateTime::Calendar::Mayan-from_object( object = DateTime-now(time_zone = 'Europe/Amsterdam')- set_time_zone = 'floating' )); The easiest thing to do would be to catch that stuff in the constructor. However I had assumed that a baktun could be 0-20 as 1 pictun = 20 baktun. Do you have source of documentation you could point me at? Look at all the websites saying the world will end in 2012. They are based on the Mayan calendar, which reaches it's new year (13.0.0.0.0) in December 2012. Or look at the calendar FAQ, as Abigail said. (The link can be found on http://datetime.perl.org .) Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Joshua Hoblitt schreef: Wrong answer #2: print DateTime::Calendar::Mayan-from_object( object = DateTime-now(time_zone = 'Europe/Amsterdam') ); So you are proposing something like this? print DateTime::Calendar::Mayan-now( timezone = 'Europe/Amsterdam' )-date; Either that, or your module should convert from the _local_ rd values, instead of the _utc_ values. (Dave's proposal) That would make Wrong answer #2 work; I'd settle for that. It would mean changing the rules, of course. As you said, the behaviour is correct as it is; I'd keep it this way until a better solution is available. Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, 3 Apr 2003, Joshua Hoblitt wrote: Actually, I'm starting to think that it might be better instead to simply have a local_rd_values method and use that instead, maybe. Or barf on floating times. Or document it. In practice, I think _most_ people working with multiple calendar systems will not even care about the time component, and will be doing stuff like: my $date = DateTime-new( year = 1900, month = 7, day = 6 ); my $mayan = DateTime::Calendar::Mayan-from_object( object = $date ); # display mayan date $mayan-add( baktuns = 2 ); my $new_date = DateTime-from_object( object = $mayan ); # display Gregorian date In this case, since floating has the same utc_rd_values as local_rd_values, everything works just fine. I think trying to impose modern time systems on ancient calendar is not very feasible. So the million dollar question is should DT::C::Mayan support timezones? Or is UTC the right thing to do? I'd say supporting time zones in other calendars is probably not worth the effort, even if we could agree on what correct support would look like ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
2) If you want to use the Mayan calendar *now*, as a replacement for the Gregorian calendar, you also need a time system. And 'our' system is the only sensible candidate. (Unless the Mayan time system is known?) You lost me on the you also need a time system. Why? If you want to replace DateTime with DateTime::Calendar::Mayan, you want to have at least comparable functionality. If you want your server logs, or your diary, or your system clock, to show Mayan dates, you also want to include a time. Perhaps I should have said: If I want to use the Mayan calendar *now*, as a replacement for the Gregorian calendar, I also want a time system.? (I accept that it would be _wrong_ to include a time. But that doesn't mean it isn't right!) So write a DateTime::Time as an abstract base class for all the calendars that don't have a time system. :) I don't think it's worth getting into a holy war about messing with calendar X. I think it's reasonable to go to the pragmatic route and say a lot of people would like to have HMS support in most of the DT:Calendars. -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Wrong answer #2: print DateTime::Calendar::Mayan-from_object( object = DateTime-now(time_zone = 'Europe/Amsterdam') ); So you are proposing something like this? print DateTime::Calendar::Mayan-now( timezone = 'Europe/Amsterdam' )-date; Either that, or your module should convert from the _local_ rd values, instead of the _utc_ values. (Dave's proposal) I have the feeling that this could lead to strange errors when chaining calendars together. I'd rather see floating time become equivalent to UTC. That would make Wrong answer #2 work; I'd settle for that. It would mean changing the rules, of course. As you said, the behaviour is correct as it is; I'd keep it this way until a better solution is available. Agreed. :) -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, 3 Apr 2003, Eugene van der Pijll wrote: And this works. But even more people will use DateTime-now. And then a floating time would be wrong. Why would a floating time be wrong then? As an example, the first program I wrote using DateTime::Calendar::Mayan. use DateTime; my $d = DateTime-now; $d-set_time_zone( 'Europe/Amsterdam' ); $d-set_time_zone( 'floating' ); print $d-strftime(%A %d %B %Y\n); use DateTime::Calendar::Julian; $d = DateTime::Calendar::Julian-from_object( object = $d ); print $d-strftime(%A %d %B %Y Julian\n); use DateTime::Calendar::Pataphysical; $d = DateTime::Calendar::Pataphysical-from_object( object = $d ); print ucfirst $d-strftime(%A %d %B %Y [%*]\n); use DateTime::Calendar::Mayan; $d = DateTime::Calendar::Mayan-from_object( object = $d ); print $d-date, \n; Can you show the output and explain the problems? Honestly, I have no clue what this _should_ print. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
'First' Post!
I just used DateTime for the first time .. in a REAL application! Sure it's just to display the time in a strftime, but it's a REAL project! Woohoo! Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Dave Rolsky schreef: On Thu, 3 Apr 2003, Eugene van der Pijll wrote: And this works. But even more people will use DateTime-now. And then a floating time would be wrong. Why would a floating time be wrong then? (I think I meant to say 'a utc time', as now() returns a 'utc' time. However, when converting it to other calendars, utc and floating work identically.) now() doesn't always return today's (local) date. If you want that, you need the time_zone. Calendars that are tz aware, also show the correct (local) date. Calendars that do not know about time and time zones, show the utc date. As an example, the first program I wrote using DateTime::Calendar::Mayan. use DateTime; my $d = DateTime-now; $d-set_time_zone( 'Europe/Amsterdam' ); $d-set_time_zone( 'floating' ); print $d-strftime(%A %d %B %Y\n); Can you show the output and explain the problems? Honestly, I have no clue what this _should_ print. It shows the correct output, because of the workaround (two calls to set_time_zone). If you remove the second one (to 'floating'), you'll see that the output of the last two calendars can be inconsistent with the output of the first two. (Try an offset of '+1200' or '-1200' in the first call to time_zone, and compare with the always correct ouput in timezone 'utc' to see the problem more clearly. At this moment: UTC: it's Thursday 03 April 2003 Thursday 21 March 2003 Julian Jeudi 12 Clinamen 130 [St Georges Dazet, poulpe au regard de soie] 12,19,10,2,10 +1200: it's Friday 04 April 2003 Friday 22 March 2003 Julian Jeudi 12 Clinamen 130 [St Georges Dazet, poulpe au regard de soie] 12,19,10,2,10 The first two are correct. The last two do not implement times, and are wrong.) Apologies for the unclearness. But it's already late, here in +0200. Eugene
Re: Bundle::DateTime
* Hill, Ronald ([EMAIL PROTECTED]) [03 Apr 2003 23:11]: [...] It may also be useful if someone who uses Windows, and knows how to do it, could produce PPMs and a PAR. I may be able to help out here. I currently have 2 version of perl (5.6.1 5.8.0) on my W2K box. along with visual studio 6.0 It has been a while since I have created a PPM but I'm sure I could pick it up again. Excellent! As for PAR I have never worked with it so I can't say. It's probably much the same. IIRC, it's a case of building the module(s) and then zipping the 'blib' directory and calling that a .par file. http://search.cpan.org/author/AUTRIJUS/PAR-0.67/ If it's too much trouble, don't worry about it. cheers, -- Iain.
