Re: About the next version of DateTme::Event::Sunrise

[Rick Measham]

What if you implemented it as 'spin' or 'hour' or 'spin_hour' or 
whatever, as a number and (optionally) exported constants to signify the 
algorithm? That means users could either provide their own number, or 
could use one of the provided.


I don't write much perl any more so forgive me if I get the syntax wrong 
here ...



    use DateTime::Event::Sunrise qw/SIDEREAL SCHLYTER/;

    my $sunriseset = DateTime::Event::Sunrise->new(
 latitude  => 42.3358,
 longitude => -71.2044,
 altitude  => '-0.833',
 precise   => 1,
 hour  => SIDEREAL);


- Rick


On 6/20/2020 2:03 AM, Jean Forget wrote:

Following the creation of RT ticket
https://rt.cpan.org/Public/Bug/Display.html?id=132336
I have decided to implement the proper precise algorithm in
DateTime::Event::Sunrise (already implemented in Astro::Sunrise) and
to check the values with NOAA's solar calculator and with Stellarium.

After I have implemented the proper precise algorithm, there are still
differences between the values obtained by Stellarium and the NOAA on
one side and by DT::E::S on the other side. I have found that these
differences are the caused by the "magic" values 15 and 15.04107 used
in the module.

15.04107 is the angular speed of Earth's spin, while 15 is the
combination of Earth's spin with the orbital speed of the
Sun-Earth system. According to Paul Schlyter 's description of
the precise algorithm, we should use 15.04107, but I have found
that using 15 instead gives results closer to Stellarium.

More abstractly, the problem is: when you are an low-level
amateur astronomer, who is an authoritative source for you?
Whom do you trust? Paul Schlyter or the Stellarium team or
the NOAA?

I have decided to defer this question to the module user. There is a
new parameter, "algo", which lets the user choose between trusting
Paul Schlyter more than Stellarium or trusting Stellarium more
than Paul Schlyter.

Now you may code either

  my $sunriseset = DateTime::Event::Sunrise->new(
 latitude  => 42.3358,
 longitude => -71.2044,
 altitude  => '-0.833',
 precise   => 1,
 algo  => 'Schlyter');

or

  my $sunriseset = DateTime::Event::Sunrise->new(
 latitude  => 42.3358,
 longitude => -71.2044,
 altitude  => '-0.833',
 precise   => 1,
 algo  => 'Stellarium');

Can you think of a better name for the new option? The creator of
ticket 132336 suggests
  spin => 15.04107,
or
  spin => 15,

The problem is that the "magic" value 15.04107 is not easy to remember,
especially if the module user knows even less astronomy than myself.
While "Schlyter" and "Stellarium" are easier to remember.

I will release the new version of DT::E::S to CPAN next week.
If you have a better idea for the name of the new parameter, please
tell me before this release.

In the meantime, the updated code is available on Github.

Thank you for your advice,

By the way, this is the second attempt to write this message
to the datetime mailing list. As it happened already, my first
attempt was lost somewhere and did not reach you or the websites
https://www.nntp.perl.org/group/perl.datetime/
and https://www.mail-archive.com/datetime@perl.org/.

Jean Forget

--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: How to check if a DateTime is invalid (again - but this time without using eval)?

[Rick Measham]

On 3/07/2017 17:44, Binarus wrote:

This answer has 49 upvotes, so can't be too wrong.


Oh no, this is the internet.

That's likely 49 other people don't know the answer, but want to look 
smart.


- Rick


--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: How to check if a DateTime is invalid (again - but this time without using eval)?

[Rick Measham]

I'm not sure what you mean by 'local DIE handlers'. Are you talking 
about defining a local $SIG{__DIE__} ?


I've been out of perl for a couple of years, but surely you should just 
use eval{} ?



$dt = eval { $parser->parse( $input );};

if( $@ ){

   echo "Unable to parse your date ($input)\n";

   exit;

}

echo "Your date is $dt\n";


- Rick



On 3/07/2017 17:49, Binarus wrote:

On 02.07.2017 22:02, Eric Brine wrote:

`eval BLOCK` is very different `eval EXPR`.

The latter involves the need to generate Perl code, and ask the related
risks. That's not the case for the former, which is the right tool for
the job here.


Thank you very much for your answer. I have decided to solve my problem
by using a block eval, probably with a local DIE handler added in the
block (but still thinking about whether this is necessary - I won't use
other DIE handlers and don't need to "catch errors" at any other places).

Regards,

Binarus


--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: DateTime and Etc timezones

[Rick Measham]

> I don't understand [why] it is not already in the DateTime module

Because it doesn't make a lot of sense. GMT+6 doesn't allow for daylight 
savings changes and any other historic changes. it requires your users 
to come to the site twice a year to adjust their time zone.


Instead you should offer them the list of time zones that DateTime gets 
from the Olson database. This is the library that every Linux 
distribution that I'm aware of uses. Often either using a GUI map, or a 
multi-step selection. Microsoft use a similar interface when selecting a 
time zone, and I imagine Apple use the Olson database.


- Rick



On 2016-06-27 13:59, Steve James wrote:
Thanks for your reply.  I just edited my timezone.txt file (attached) 
that the code uses as the "guts" for the timezones select.  The change 
seems to be working ok, but still keeping my fingers crossed...


My only point is, though, that since this such a simple thing, I don't 
understand what it is not already in the DateTime module.  ;-(

ᐧ

On Sun, Jun 26, 2016 at 8:53 PM, Eric Brine > wrote:


$timezone = sprintf("%+04d", $_*100) if $timezone =~ m{^Etc/GMT(.+)};

On Sun, Jun 26, 2016 at 11:44 PM, Steve James
<4steveja...@gmail.com > wrote:

Thanks for your reply.

My users select a timezone from a list.  I do not think that
+0600 will be as clear as Etc/GMT+6, so it looks like I am
going to have to do a workaround for this.  ;-(

I think I can maybe store +0600 but show Etc/GMT+6 to the user
(via an HTML select), but I will have to see...
ᐧ

On Sun, Jun 26, 2016 at 8:18 PM, Eric Brine
mailto:ikeg...@adaelis.com>> wrote:

It does, however, support "+" and "-".

$ perl -MDateTime -E'DateTime->today(time_zone =>
"+0600"); say "ok"'
ok


On Sun, Jun 26, 2016 at 11:13 PM, Steve James
<4steveja...@gmail.com > wrote:

I am the principal developer for the FreeToastHost
website system, a free website provider, content
management system, and email list server used by over
10,000+ Toastmasters public speaking clubs worldwide.
Toastmasters is a non-profit and much of the labor to
support clubs is done on a volunteer basis.
FreeToastHost is an independent effort created by
Toastmasters club members from open source libraries
and via volunteer labor.  (myself included)
FreeToastHost uses a number of your DateTime module
functions.

We have recently ran into an issue where it appears
that DateTime does not support "Etc/" style names for
timezones.  (e.g. "Etc/GMT+6")

For example, the following produces an exception for
me when running in a plain vanilla test script:

  my $today = DateTime->today(time_zone =>
'Etc/GMT+6');


Is there something I am missing or is this as intended?

-- 
/*Steve James*/

*Linkedin: **http://www.linkedin.com/in/sejames*
ᐧ





-- 
/*Steve James*/

PE, CPE, PMP, Six Sigma Blackbelt
*Cell:* 818-570-1197 
*Email:* 4steveja...@gmail.com 
*Linkedin: **http://www.linkedin.com/in/sejames*





--
/*Steve James*/
PE, CPE, PMP, Six Sigma Blackbelt
*Cell:*  818-570-1197
*Email:* 4steveja...@gmail.com 
*Linkedin: **http://www.linkedin.com/in/sejames*

Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam 
and content filtering.

http://www.mailguard.com.au 


Report this message as spam 
 





--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Did April go missing in Asia/Amman?

[Rick Measham]

This is _why_ you get an error. But the month still started. I think this 
should be considered to be a bug. Truncating to month in Amman should return 
2016-04-01T01:00:00. 

- Rick
📱

> On 23 Apr 2016, at 08:51, Zefram  wrote:
> 
> Bill Moseley wrote:
>> Why can't I truncate to the month?
> 
> Because 2016-04-01T00:00:00 didn't exist in Asia/Amman.  Its DST rules
> include a switch from winter time to summer time at 24:00 on the last
> Thursday in March.  This has the effect of skipping the hour from 00:00
> to 01:00 on some Friday morning.  This year the last Thursday in March was
> the last day in March, so the affected Friday was the first day of April.
> 
> -zefram
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://console.mailguard.com.au/ras/1Oi2T9HaXu/6j0APGxp3PNU2sgOlfcTIG/0.01
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Status of DateTime::Event::Easter

[Rick Measham]

On 16-Jan-15 07:53, Jean Forget wrote:

I have noticed that your module has not been updated till 2004.


Hi everyone! Happy DateTime->now() to you all.

As Jean pointed out above, I have not done much on DateTime in quite a 
while. I don't play much in perl any more, but remain proud of the work 
I have done in the past and the DateTime project overall.


I have a number of modules I'm the maintainer for. Some of them are 
useful, others are .. less so.


If you have the willingness, skill and experience I'm more than happy to 
put any of these up for adoption.

* DateTime::Format::Baby
* DateTime::Format::Duration
* DateTime::LazyInit
* DateTime::TimeZone::LMT

I wrote the original DateTime::Format::Strptime that is now maintained 
by Dave Rolsky and have just made Jean the (co)maintainer of 
DateTime::Event::Easter, so if you want to work on either of those, 
please speak to those gentlemen.


Regards,
- Rick




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Status of DateTime::Event::Easter

[Rick Measham]

Hi Jean,

Thanks for poking me on this. I don't spend much time coding any more. 
And even less, coding in perl. And even less coding in DateTime!


If you're willing to take over the maintenance then I have no problem 
with that at all. You'll need to remind me what I need to do to make 
that happen however.


I built this as part of some work I was doing way-back-when that was 
aimed at creating a liturgical calendar that would deal with all the 
tiny ridiculous rules that go into determining different feast days and 
other holy days! In the end I let that go and all I got done was Easter.


Regards
- Rick

On 16-Jan-15 07:53, Jean Forget wrote:

To all users of DateTime::Calendar::Discordian, my best wishes for YOLD
3181

And to all users of Julian and Gregorian calendars (through the use of
DateTime::Calendar::Julian and DateTime), happy new year 2015.

Now, to Rick about DateTime::Event::Easter:

I have noticed that your module has not been updated till 2004. It
appears in Neil Bowers' list of CPAN Adoption Candidates with a score
of 8. There are 3 current RT issues (actually 4, but RT 79041 and RT
101238 are duplicate IMHO). All three issues are about the POD
documentation and all three include a patch, but you should note that
there are 458 failures by the CPAN testers and RT 79041 explains these
failures.

http://neilb.org/adoption/
https://rt.cpan.org/Ticket/Display.html?id=7598
https://rt.cpan.org/Ticket/Display.html?id=51892
https://rt.cpan.org/Ticket/Display.html?id=79041
https://rt.cpan.org/Ticket/Display.html?id=101238

So, are you still maintaining this module?  Do you have problems which
prevent you to update this module (commitments elsewhere, for
example)?  Are these problems permanent or do you think they could be
solved within, say, a few months?

If necessary, you can give me co-maintenanceship so I can release a
new version of the module to CPAN.  I have already forked the GitPAN
repo to work on the module, so I can already work on the module.
Beyond applying the patches from the RT tickets, I have a few other
ideas to improve the module.

1) Fix the kwalitee issues
http://cpants.cpanauthors.org/dist/DateTime-Event-Easter

2) Add the GPL-mandated comments in all code files.  If you read the
Appendix to the GPL "How to apply these terms to you new programs",
you notice that you have to insert some comments at the beginning of
each source file. I consider that "each source file" includes the test
files "t/*.t", so I insert the GPL summary in these test files also.

3) New functionality: add the long range feasts and events associated
with Easter: fat tuesday, ash wednesday, ascension and pentecost.  OK,
you can already do this if you know the numerical value of the offset,
but it would be nicer if the offset can be provided by the module.

4) Improve the code coverage by the "t/*.t" test files.

5) New functionality: public API for the Golden Number and the Epact.

I have already implemented (1) and (2) in my Github repo. I have time
to implement (3) and begin (4) while waiting for your approval for
co-maintenanceship. (5) can wait for the next release.

Best regards,

Jean Forget
(JFORGET on CPAN)







smime.p7s
Description: S/MIME Cryptographic Signature

Re: Parsing performance...

[Rick Measham]

First note is that Strptime is designed to be flexible. Speed wasn't the goal. 
That said, it also wasn't designed to be slow! 

Second, and most importantly, your benchmark should fare MUCH better if you 
don't create a new parser every time. Create the parser outside the benchmark 
sub and it should be muuch quicker. And that is how your production code 
should work. 

- Rick
📱

> On 31 Jan 2014, at 5:58, Marcin Kasperski  
> wrote:
> 
> 
> I was optimizing some log-parsing script today, and found 
> DateTime::Format::Strptime to be bottleneck. Out of curiosity I wrote
> simple benchmark. Code is here:
>http://pastebin.com/PU8nXGPW 
> 
> Results are interesting, as they show fairly noticeable differences:
>http://pastebin.com/S4rt6bYd
> (run on Ubuntu 12.04 with perl 5.14.2 and ubuntu-packaged datetime
> modules)
> 
> While the fact that „trying many approaches” parses like Natural or
> Flexible are slow is, well, natural (still DateParse is much better),
> I find it confusing that Strptime is soo slow. ISO8601 parser also
> has fairly strict syntax to handle so I expected it to perform better...
> 
> Any insights? And which parsing method would you recommend to get
> optimal performance?
> 
>  Sidenote ~
> 
> DateTime::Format::Builder does not give any easy way to treat
> „below-second” part with float semantic (treat .12 as 120 miliseconds,
> treat .1347 as 134700 microseconds, etc). In spite of the fact, that
> this is most natural and ... only sensible semantics.
> 
> As you can see from my code and it's results, DateTime::Format::Flexible
> falls into this trap (treats those digits as nanoseconds even if there
> are less than 9 of them), while my hand-made builders require
> postprocessing to clean this field up.
> 
> Am I missing sth? Is there a way to handle this better?
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1ITnAf1Ld9/7AiiWUInKq0y5APy9tARIw/0
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: First time of the day

[Rick Measham]

Back in 2003 I wrote the beginnings of DateTime::Event::DST which you can see 
here: http://marc.info/?l=perl-datetime&m=106716694406817&w=2

It didn't go far beyond that. After Flavio's comment it descended into chatter 
about which way the toilet flushes, and I've no idea if the code there would 
help. YMMV.

Cheers!
Rick Measham
📱

> On 28 Dec 2013, at 5:29, Eric Brine  wrote:
> 
> Hi!
> 
> Given a date and time zone, is it possible to obtain the first time of that 
> date?
> 
> For example. in America/Sao_Paulo, 2013/10/20 started at 01:00 rather than 
> the usual midnight.
> 
> I've also asked this on StackOverflow, where I posted a potentially incorrect 
> solution.
> http://stackoverflow.com/q/20805667/589924
> 
> - Eric
> 
> 
> Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.
> http://www.mailguard.com.au
> 
> 
> Report this message as spam  
>  
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: DateTime::Duration->compare() return value is not specified in the documentation.

[Rick Measham]

  

Hi Andreas, 

It does need to be documented, but to explain:
$dt->compare follows the behavior of `cmp` and ``. 

- Rick 

On Thu, 10
Oct 2013 10:07:02 +0200, Andreas Isberg wrote: 

> Hi, 
> The
documentation does not specify what What does
DateTime::Duration->compare() returns. 
> From some testing I've done it
seems like it 
> 
> * 1 if the first duration is larger than the second,

> * 0 if the durations are equal 
> * -1 is the second duration is
larger than the first
> 
> Can anyone confirm this, and possibly update
the documentation? 
> Documentation is found here:
http://search.cpan.org/~drolsky/DateTime-1.03/lib/DateTime/Duration.pm#DateTime::Duration->compare(_$duration1,_$duration2,_$base_datetime_)
[1] 
> Kind regards, 
> Andreas Isberg
> 
> Telefon: 072-588 91 95 
>

> Message protected for iSite by MailGuard: e-mail anti-virus,
anti-spam and content filtering.
> http://www.mailguard.com.au [2] 
>
Report this message as spam [3]

  

Links:
--
[1]
http://search.cpan.org/~drolsky/DateTime-1.03/lib/DateTime/Duration.pm#DateTime::Duration->compare(_$duration1,_$duration2,_$base_datetime_)
[2]
http://www.mailguard.com.au/rm
[3]
https://login.mailguard.com.au/report/1I9kqknXTc/2eG4yrlviF9PLZ81IBzAU4/0.002
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Issue with finding next DST change, date math error?

[Rick Measham]

Not a bug in DateTime. This is consistent with the C libraries that underpin 
Perl and other stuff. If you call the internal time() function every second 
over a leap second you'll see the same epoch value twice. It's about defining 
what the epoch second actually means. It's the number of solar seconds since 
jan 1, 1970. 

As the earth's rotation doesn't evenly divide into the number of seconds that 
have elapsed, we occasionally need to skip or add a second. Just like we have 
to add a day every ~4 years. 

The problem is that epoch seconds are serial so it's a lot weirder. If we had 
epoch days, you'd see a double up every ~4 years so that years were always a 
multiple of 365. (Imagine if leap seconds actually skewed the epoch by a second 
how hard it would be to use them?  (eg: time() % 86400))

Cheers!
Rick Measham

On 25/05/2012, at 23:08, Anthony Ball  wrote:

> So is that a bug in DateTime? If I subtract one epoch time from another and
> add shouldn't they end up together? Or is it just too weird to code for?
> 
> Maybe a better solution than adding seconds would be just moving to that
> epoch slice, I'd have to create a new datetime using from_epoch (unless
> there is a way to do that on an existing object other than date math) but
> it would remove any math inconsistencies.
> 
> I was wondering about leap seconds since it only happened in that one time
> frame but wasn't sure where to check for it, thanks.
> 
> On Fri, May 25, 2012 at 6:40 AM, Zefram  wrote:
> 
>> Anthony Ball wrote:
>>> I never had any luck finding anything to give me the future DST changes
>> for
>>> a timezone
>> 
>> We don't have an API for that.  We've discussed it a bit, and will most
>> likely add such a thing to the DT:TZ API after we've switched to the
>> reimplemented DT:TZ, scheduled for 2012-09-01.
>> 
>>>  Now however the second
>>> change in 2012 is coming up one second short,
>> 
>> Smells like a leap second issue.  There's a leap second scheduled for
>> 2012-06-30T23:59:60Z.
>> 
>> -zefram
>> 
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1EOfrXTUQv/96CbBBv21MNXe8uQWnhfs/0.8
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Issue with finding next DST change, date math error?

[Rick Measham]

Back in 2007 I wrote about some code I wrote in 2003. No idea if it'd be 
useful. 

http://grokbase.com/t/perl/datetime/073612z62x/event-dst-pulling-dst-changes-from-datetime

Cheers!
Rick Measham
📱

On 23/05/2012, at 6:59, Anthony Ball  wrote:

> I never had any luck finding anything to give me the future DST changes for
> a timezone so I worked out how to get it on my own, but recently I upgraded
> from something like DateTime 0.36 to 0.74 and something really strange is
> happening.
> 
> In my code I set the date to the start of the year and then use an
> undocumented internal timezone call _span_for_datetime to get the next
> change,  then I pull utc_rd_as_seconds one subtracted from the other allows
> me to add the proper seconds to move forward to the next change, store it,
> then roll and repeat until I have what I want. Now however the second
> change in 2012 is coming up one second short, even though the offsets are
> the same, and it seems to be other timezones as well, not just New York.
> Asia/Gaza for instance.
> 
> Using the old code I get "2012-03-11T03:00:00 2012-11-04T01:00:00" for New
> York,
> but the new DateTime gives me "2012-03-11T03:00:00 2012-11-04T01:59:59",
> one second before the actual change.
> 
> Is this a bug in my code or something weird in DT. Of course I'm using
> various calls that are unsupported externally so I shouldn't be surprised
> when things go south, but the numbers are the same between one and the
> other so maybe I'm doing something wrong, wouldn't surprise me. I even
> tried converting to utc before doing my math and then back as the perldoc
> suggests with no joy.
> 
> A slightly simplified version of my code follows... I've found a workaround
> but would like to understand the problem.
> 
> use DateTime;
> # pass year timezone
> print "@{get_dst_changes($ARGV[0],$ARGV[1])}\n";
> 
> sub get_dst_changes {
>my $year = shift;
>my $tz   = shift;
>my ( $DT, $DT_end );
> 
>eval { $DT = DateTime->new( year => $year, time_zone => $tz ); };
>return if $@;
>$DT_end = $DT->clone();
>$DT_end->add( years => 1 );
> 
>my $i = 0;
>my @out;
>my $DT2;
>while ( $i++ < 100 ) {#in case we start looping for some reason
>my $span = $DT->{tz}->_span_for_datetime( 'utc', $DT );
>my $seconds = $DT->utc_rd_as_seconds();
> 
>if ( $span->[UTC_END] =~ /\+/ ) {
>last;
>}
>my $change = $span->[UTC_END] - $seconds;
> 
># Find the offset and add it. Now we have a DateTime object AT DST
> change
>$DT->add( seconds => $change );
> 
>$DT2 = $DT->clone();
>$DT->add( seconds => 1 ); # One second past allows us to search for
> the next DST change
>last unless $DT < $DT_end;
> 
>push @out, $DT2;
>}
>\@out;
> }
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1EO02gepzC/1mXz3HoAzKmVJJ1MNVgifT/0.2
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Olson querying

[Rick Measham]

Magic!

Cheers!
Rick Measham
📱

On 09/05/2012, at 6:38, mer...@stonehenge.com (Randal L. Schwartz) wrote:

>>>>>> "Rick" == Rick Measham  writes:
> 
> Rick> $ olson time 13:48   # where is it currently 13:44?
> Rick> $ olson time 13:48 -Cau  # where in Australia is it currently 13:44
> 
> Does it offset by 4 minutes automatically?
> 
> :-)
> 
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
>  http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.posterous.com/ for Smalltalk discussion
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1EHdSoFRAS/5NsrA9R5r7L6i9em677WM1/0
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: DateTime performance

[Rick Measham]

In the spirit of TIMTOWTDI, there's my DateTime::LazyInit module which I wrote 
for this sort of case. It only inflates to a full DateTime object when you call 
methods that aren't "simple". 

http://search.cpan.org/~rickm/DateTime-LazyInit-1.0200/lib/DateTime/LazyInit.pm

Caveat: I haven't tested it against any recent DateTime releases. 

Cheers!
Rick Measham
📱

On 02/05/2012, at 8:29, "Philipp K. Janert"  wrote:

> 
> Question:
> 
> When using DateTime for a large number of
> instances, it becomes a serious performance
> drag. 
> 
> A typical application for me involves things like
> log files: I use DateTime to translate the timestamps 
> in these files into a canonical format, and then get 
> information such as "day-of-week" or "time-of-day" 
> from DateTime. 
> 
> However, when working through a files with a few 
> tens of millions of records, DateTime turns into a 
> REAL drag on performance.
> 
> Is this expected behavior? And are there access
> patterns that I can use to mitigate this effect? 
> (I tried to supply a time_zone explicitly, but that
> does not seem to improve things significantly.)
> 
> Best,
> 
>Ph.
> 
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1EEXMobD68/14EZiTvCo3I3sbAw7UgxdE/0
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Olson querying

[Rick Measham]

Nice utility.

I wouldn't mind something like this too:

$ olson time 13:48   # where is it currently 13:44?
$ olson time 13:48 -Cau  # where in Australia is it currently 13:44
Australia/Currie
Australia/Hobart
Australia/Lindeman
Australia/Melbourne
Australia/Sydney

Feels like a useful way to offer a limited number of zones to a customer 
when you know their localtime (eg. in a web interface)


Cheers!
Rick Measham


On 6/03/2012 9:21 AM, Zefram wrote:

New version of the query tool attached.  This one has a lot more options
for searching for zones.  It lets you ask questions like:

 $ olson areas -Cru # where is Russia?
 Asia
 Europe

 $ olson offsets -ICST # what does "CST" mean?
 -06
 -05
 +08
 +09:30
 +10:30

 $ olson zones -Cau -IEST # which zone might EST be in Australia?
 Australia/Brisbane
 Australia/Currie
 Australia/Hobart
 Australia/Lindeman
 Australia/Melbourne
 Australia/Sydney

I've got a todo list with a bunch more features that it ought to
support searching on, but I think I'm going to handle them by a radical
refactoring that yields more of a query language than this collection
of options.

-zefram




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Error with the leap year

[Rick Measham]

> If months are day offsets into the year, and day-of-month is the additional 
> days to add to the offset, and this approach is applied to smaller levels 
> too, all the screwey questions can fall into place.


And that is how date math works in DateTime. It's just not what the OP did. 

2.30a on March 10 is another case in point. If you SET the day to March 11, 
it's an error: there is no 2.30 on March 12 as its the start of DST. 

This is where the OP made his mistake. He SET the year to 2013. If he'd added a 
year to his date, all would have been (possibly*) fine.   

DateTime's strength lies in its accuracy, and an important part of that is 
validation. 

If you want to add a day, add a day. It works as you'd expect. 

Cheers!
Rick Measham
📱

* Possibly not. 
Imagine we're operating a dam and in order to be well prepared we issue a new 
command every day: in one years time, spill a gigalitre. Now next Feb 28, well 
be spilling two and destroying a village of 1384 people and their 413 goats!!!
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Error with the leap year

[Rick Measham]

> no matter how clearly or thoroughly a document is written
> there will always be someone that will misread and misuse it.

Or read the synopsis and decide the module's use is obvious without reading the 
documentation. 

I've been guilty of that with other modules. Perhaps we also need a warning at 
the top of the synopsis?

Cheers!
Rick Measham
📱
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Error with the leap year

[Rick Measham]

No configuration option is required in this case. The OP isn't having trouble 
with date math: that would have done what he wanted.  

He's using the set() method to set the object to a date that doesn't exist. Any 
behavior beyond an error would be incorrect. 

Should ->new( year => 2012, month => 13, day => 42 ) assume you wanted Dec 31? 
No, it's an error. 

If you wanted 13 months, 42 days after Jan 1st 2012, then you should be using 
date math. 

Cheers!
Rick Measham
📱

On 03/03/2012, at 5:14, Karen Etheridge  wrote:

> On Thu, Mar 01, 2012 at 08:26:13PM -0800, Michael G Schwern wrote:
>> On 2012.3.1 2:14 PM, jonathan.pey...@ubs.com wrote:
>>> If the date for $dt is 20120229, the following produces an error!
>>> 
>>> $dt->set_year($dt1->year + 1);
>>> 
>>> Invalid day of month (day = 29 - month = 2)
>> 
>> This error is correct, there is no Feb 29, 2013.
>> 
>> It could return March 1, 2013... but then adding a year to Feb 29, 2012 and
>> adding a year and a day give the same result which doesn't make sense.
>> 
>> It does present a problem... how do you reliably say "same date next year"?
> 
> This is very similar to the 'end_of_month_mode' feature in
> DateTime::Duration, which handles how (for example) "Jan 30 + 1 month"
> calculations are handled.  Therefore, I would suggest a configuration
> option for handling how wrapping is done involving leap years.
> 
> For that matter, leap seconds pose the same problem - if 00:00:60 is a
> leap second, how does one handle 00:00:60 + 1 minute? is it wrapped to the
> next minute (00:02:00), truncated (00:01:59), or...?
> 
> 
> -- 
>   #!/bin/perl -sp0777i   $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
>   lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
>. ... .
> Karen Etheridge, ka...@etheridge.ca   GCS C+++$ USL+++$ P+++$ w--- M++
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1EfBtCKdpY/2VzzLrnXo9n13n6snrZNTJ/0
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Is there a bug in timelocal()

[Rick Measham]

In Time::Local, to match perl's internal localtime(), months start at zero. So 
you're trying for April 31st. 

Cheers!
Rick Measham


On 15/04/2011, at 9:39, "Nithi, Nachi K (Karun)"  
wrote:

> Example code:
> 
> #!/usr/bin/perl -w
> select(STDOUT); $| = 1; # make unbuffered
> 
> use Time::Local;
> 
> $tdate = "31/03/2011";
> $ttime = "14:49:59";
> $mday  = $mon = $year = 0;
> $hour = $min = $sec = 0;
> 
> ($mday,$mon,$year) = split('/',$tdate);
> ($hour,$min,$sec)  = split(':',$ttime);
> print "mday =  $mday \tmon = $mon\tyear = $year\n";
> print "hour =  $hour \tmin = $min\tsec = $sec\n";
>$uxtsec = timelocal($sec,$min,$hour,$mday,$mon,$year);
> print "timelocal_sec = $uxtsec\n";
> #---#
> 
> Result:
> 
> $ ./tl.pl
> mday =  31  mon = 03year = 2011
> hour =  14  min = 49sec = 59
> 
> Error:   Day '31' out of range 1..30 at ./tl.pl line 15
> 
> 
> Is there a bug? The 'mday' range in the doc says 1..31 and it is 31 here. But 
> complains about out of range.
> 
> 
> Thanks,
> 
> 
> Dr. Nachi Nithi
> Bell-Labs, Alcatel-Lucent
> 2C-323, Mountain Ave.,
> Murray Hill, NJ 07974
> Ph: 908-582-3590
> Home: 
> http://ect.bell-labs.com/who/karun//index.html<http://ect.bell-labs.com/who/karun/index.html>
> -
> 
> 
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1C7jlMg48w/FTZOfbEeOXsCvNVcE9ife/0
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: How to distinguish between no month/day and 01/01?

[Rick Measham]

Many current parsers use DateTime::Format::Strptime as their "real" 
parser. I'd suggest that we modify strptime to accept an 'incomplete' 
option that doesn't croak when you don't supply enough parameters but 
instead returns a DateTime::Incomplete object.


Once that's done, any parser that uses it just needs to be made 
"incomplete aware". In some cases (ISO8601) being 'incomplete' will 
depend on the format it's parsing. Eg "2011" is a valid 8601 format. 
DT:F:ISO8601 would call strptime with { pattern => '%Y', incomplete => 1 }.


This wouldn't be a difficult modification to strptime, and would provide 
an easy route to ::incomplete for other parsers that already use 
strptime for parsing.


Cheers!
Rick Measham


On 29/03/2011 9:37 AM, Karen Etheridge wrote:

I just started using DateTime::Incomplete for a project and discovered that
would be handy to have a string parser, so I came back and re-read this
thread :)

Regarding the message quoted below, my assessment is that all that is
needed to be written (from scratch) is a DateTime::Format::Incomplete::Builder
module -- then the various DateTime::Format::YourType modules can be mostly
recycled into passing their parsers into this new modules.

Alternatively, it might be possible to change the DateTime::Format::*
family into constructing other object types (than vanilla DateTime), but
that sounds like a refactoring pass to follow the initial version as I
described above.



On Wed, Feb 23, 2011 at 06:47:37PM +0100, Philip Kime wrote:

Greetings,
   I can't seem to find a DateTime::Format module which will leave day/month undef if I 
pass just a year like "2008". When parsing bibliographies, it's important to be 
able to distinguish between, say

2008
2008-01
2008-01-01

Every module I've found sets the day or month to "1" if it's not in the input 
which makes it impossible to tell if there really is a day/month in the input without 
parsing the input (which makes using a DateTime::Format module pointless ...). Is there a 
way to do this? I know about DateTime::Incomplete but that doesn't parse dates, you have 
to have already split the date up to pass to it ...
It seems that all of the DateTime::Format::* modules parse into DateTime objects which 
always default day/month to "1".

PK
--
Dr Philip Kime




smime.p7s
Description: S/MIME Cryptographic Signature

Re: How to distinguish between no month/day and 01/01?

[Rick Measham]

Seems to me that "2003" isn't a datetime, nor is "2003-05-01", both are spans. 
2003 = '2003-01-01 00:00:00.0' - '2004-01-01 00:00:00.0'

Maybe there's something that can be done with DT:Incomplete given that change 
in perspective?

Maybe DT:F:Strptime could return a DT:Incomplete as an 'error' option. 

No solutions, just thoughts. 

Cheers!
Rick Measham


On 24/02/2011, at 17:59, Philip Kime  wrote:

> Yes, that would be fine and I could use DateTime::Incomplete to get
> what I want but unfortunately what I need is the parsing so I don't
> have to parse it all myself (which is what I'm currently doing). The
> strings aren't that simple I'm afraid, that was just a minimal
> example. In fact, the strings are so irregular in one app data source
> driver that I really need to use DataTime::Format::Natural ...
> 
> PK
> 
> On 24 February 2011 01:34, Karen Etheridge  wrote:
>> On Wed, Feb 23, 2011 at 09:23:08PM +0100, Philip Kime wrote:
>>> All I really want is to be able to say:
>>> 
>>> $dt = DateTime::Format::Somemodule->new('2008');
>>> 
>>> and have $dt->month and $dt->day return undef instead of "1" otherwise I 
>>> can't distinguish from:
>>> 
>>> $dt = DateTime::Format::Somemodule->new('2008-01-01');
>>> 
>>> Even DateTime::Format::ISO8601 doesn't do this even though "2008" is a 
>>> valid ISO8601 date.
>> 
>> If your strings really are this simple, could you not simply do $dt =
>> DateTime->new(year => 2008);  ?  The DateTime::Format::* modules are simply
>> string parsers which call DateTime->new with various arguments -- there is
>> no reason why you can't call the constructor yourself.
>> 
>> 
>> 
>> --
>> "The 3 great virtues of a programmer:
>>Laziness, Impatience, and Hubris." - Larry Wall
>>. ... .
>> Karen Etheridge, ka...@etheridge.ca   GCS C+++$ USL+++$ P+++$ w--- M++
>> http://etheridge.ca/  PS++ PE-- b++ DI e++ h(-)
>> 
> 
> 
> 
> -- 
> Dr Philip Kime
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1BMjZLkebE/36DtTOMZrBA6cRxeViXzr4/0
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Rounding a DateTime to the nearest minute

[Rick Measham]

This works in my head:

$dt->add( seconds => 30 )->truncate( to => 'minute' );

Cheers!
Rick Measham

On 01/12/2010, at 10:32 PM, "Jaldhar H. Vyas"  wrote:

> Is there a simple way to do this (i.e. 6:14:56 becomes 6:15:00, 6:14:07 
> becomes 6:14::00 etc.) or do I have to roll my own?
> 
> -- 
> Jaldhar H. Vyas 
> -- 
> Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
> content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1BdnE37tyM/28k4626s5OidVPkt2HIig2/0
> 
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: datetime::duration doesn't do what I expect and doesn't produce an error either

[Rick Measham]

G'day Paul,

I think the problem here is a misunderstanding of the disconnect between 
calculation and representation. We've been working on this project for 
years now and it's extremely unlikely to significantly change in the 
fundamental and deliberate disconnect between calculation and 
representation.


DateTime's strength is it's rigid adherence to being Correct. If you say 
there's a duration of 2 days, we don't assume you mean 48 hours as there 
could be a DST jump in that 2 days. The representation of data is 
handled by the ::Format:: classes -- including 
DateTime::Format::Duration which is aimed at formatting durations in a 
manner that makes sense to the user of the module.


Cheers!
Rick Measham


On 16/07/2010 12:15 PM, Paul Miller wrote:

On Thu, Jul 15, 2010 at 5:42 PM, Rick Measham  wrote:
   

You'd be looking for the ISO normalization in DateTime::Format::Duration.
 

Perhaps.  I actually think I'm looking for Date::Manip.  I don't think
DateTime is done cooking yet.  It's pretty difficult to use and
doesn't DWIM very well.  It will.   I'm patient.  I was just super
frustrated and wanted to get the words out there.  I'm not alone.  I
see it was just on the list the other day and it will come up again in
the future.

Cheers.

-Paul

   

--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: datetime::duration doesn't do what I expect and doesn't produce an error either

[Rick Measham]

On 16/07/2010, at 4:17 AM, Paul Miller  wrote:

> I understand there's
> ambiguity here, but I think there are some predictably acceptable
> conversions that can be done (4 weeks in a month, 7 days in a week,
> etc); and they could at least be an option.
> 
You'd be looking for the ISO normalization in DateTime::Format::Duration.

Cheers!
Rick Measham
-- 
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Span subclass in SpanSet

[Rick Measham]

On 14/05/2010 9:03 AM, Sean Robinson wrote:
Has anyone used DateTime and friends to find scheduling conflicts and 
been able to identify the offending events without walking a list of 
Spans?




A few years back I was in the same place you are right now. Have a look 
through the archive for my work on the catholic liturgical calendar: It 
has many rules about conflicts. I was planning on using DateTime to work 
out when a particular hol[iy]day was in a given year. To do that I was 
going to put everything into spans and sets in priority order, then use 
conflicts to move particluar feasts. Finally I'd have a spanset for the 
whole year. Each span in that set would then be able to return which 
holy day it was. Once that was set up, I could pass in a date and check 
for a 'conflict' in order to determine on which holy day that date fell.


And then I hit the same brick wall you have, got frustrated, wandered 
off and gave up. Sorry I can't offer you any further help, but the 
inability is so fundamental to the way spans and spansets are built that 
there would be no solution beyond created your own set of classes.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: Taking over DateTime::Format::Strptime?

[Rick Measham]

Dave Rolsky wrote:
I've written email to modu...@perl.org with the intention of taking 
this module over. I need to make it not rely on deprecated 
DateTime::Locale APIs so I can finally release a new version of 
DateTime::Locale.


If _someone_ else out there is dying to maintain this module, please 
say so.


Rick, if you're out there, please respond.


Dear Dave and the DateTimers,

Many apologies for appearing uncontactable. I'm busier and busier these 
days have have less and less time to spend on this code. Each time I've 
received an email I've planned on getting it done, but have let it slide.


I've previously said I'd take on a co-maintainer. Evan responded that 
he'd totally rewrite the module as an XS module. I've no interest in 
doing this so the module is currently still under my maintenance (and is 
therefore virtually unmaintained).


I think Strptime is a really important module for the DateTime suite, 
and has a lot more importance I've evidenced I can give to it.


Therefore, in the interests of ... well .. everybody ... I'm quite happy 
for anyone to take it over that can give it the attention it needs. I'm 
also quite happy, still, for anyone suitably qualified to be a 
co-maintainer of the current code. Again if Dave or Evan want to take it 
over, I'm quite happy for them to do so and from there it can take any 
direction the community is happy with.



Once again, many apologies for not following up on the evolving changes 
in DateTime.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.http://www.mailguard.com.au

Re: [ANNOUNCE] DateTime::Format::Strptime 1.1000

[Rick Measham]

Dave Rolsky wrote:

On Tue, 14 Jul 2009, Rick Measham wrote:

This release depends on DateTime::Locale 0.43 and the locale tests 
expect the data provided by that module. This isn't future-proof, but 
Dave says that the methods that provide the %x, %X and %c patterns to 
strftime are deprecated. Once the target stops moving, I'll try to 
future proof these tests.


I'm not sure what you mean by stops moving. You don't want to wait until 
I remove the methods, then Strptime will break altogether!


I'll consider the target to have stopped moving as soon as you've 
decided which methods are going to carry on existing and which are going 
away ..


At the moment those methods exists and are being used (by me, and 
possibly by other people who use the Locale modules). Therefore my bug 
report stands. If you're going to remove methods from objects, please do 
so very slowly and discuss on this list first -- after all, you're 
removing backward compatibility.


Once you fix the bug, I'll get the tests to work as it should. The 
problem became clear when the data I got from strftime didn't parse 
using strptime. Ideally the two methods should be symmetrical.


At the moment, strftime('%x') correctly returns 2009 (in en_US) as the 
CLDR pattern is 'y'. But the cldr->strf converter is specifying %y. When 
strptime sees %y, it expects two digits and so takes the '20' as the year.


If the methods are going away, I guess I can put the conversion into 
Strptime. It just seems to make more sense to have it live near data. 
Once you remove it, if you want the str[fp]time pattern for a locale, 
you'll have to use DT:F:Strptime.


(Maybe you could move it into DateTime::Format::Locale to turn the 
locale patterns into various formats including Str[fp]time?)


As far the locale data, that target will never stop moving. I'll keep 
releasing new versions as the CLDR folks update their data.


Well .. yeah

Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

[ANNOUNCE] DateTime::Format::Strptime 1.1000

[Rick Measham]

This release allows the 'pattern' to be a regex. This is handy for 
situations like:


pattern => '%Y-%m-%d[T ]%H:%M:%S'

where you'll accept either the 'T' or space delimiter in ISO8601 type 
datetimes.



This release depends on DateTime::Locale 0.43 and the locale tests 
expect the data provided by that module. This isn't future-proof, but 
Dave says that the methods that provide the %x, %X and %c patterns to 
strftime are deprecated. Once the target stops moving, I'll try to 
future proof these tests.



The release will be available from CPAN shortly, or you can download it 
from Google Code: 
http://datetime-format-strptime.googlecode.com/files/DateTime-Format-Strptime-1.1000.tgz


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: DateTime::Format::Strptime fails test

[Rick Measham]

Dave Rolsky wrote:
All those methods that convert to strftime patterns are deprecated and 
will go away in a future release, so even if I fixed this bug, if you're 
relying on them, your code will break eventually.


Erm .. I'm confused.

DateTime::Locale will no longer provide the strftime patterns for %c, %x 
and %X? If not, how will those be generated?


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: DateTime::Format::Strptime fails test

[Rick Measham]

L'équipe de serving.fr wrote:
We're having a problem installing DateTime::Format::Strptime (it seems 
several people have alreayd posted on 
http://www.nntp.perl.org/group/perl.datetime/ but we can't find the 
solution)


As per the documentation, the correct place to report bugs is 
http://code.google.com/p/datetime-format-strptime/issues/list


The bug you refer to is #19. There's a fix coming as soon as I can get a 
more sane test in there.


For now, just do a force install (if the only failed tests are in 
004_locale_defaults.t)




Dave:
=
I believe there's an error in DateTime::Locale::Base that is screwing 
with my fix. Line 277 turns the CLDR notation 'y' into the strftime 
notation '%y'. From my reading of 
http://www.unicode.org/reports/tr35/tr35-9.html#Date_Format_Patterns 'y' 
should become '%Y'.


Once that is fixed, I'll use DateTime's strftime to get the input data 
in the tests. That way, if the Locale returns some other data because of 
a future change, it will all test OK.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: Localised, human readable time durations

[Rick Measham]

Ton Voon wrote:
DateTime::Format::Human::Duration - 
http://search.cpan.org/~dmuey/DateTime-Format-Human-Duration-0.0.1/


Not updated since July 2008. Supports spanish, portugese, english

There is a comment that maybe this could be supported in 
DateTime::Locale instead.


1. July last year doesn't mean it's abandoned! Just that it does what it 
does and does it right.


2. Support for other languages is easy if you have the data. I'm sure 
the author would appreciate the input.


3. The comment re DateTime::Locale is pointed at the fact that the 
Locale datasource (CLDR) doesn't have any data that can be used to 
human-format a duration in each locale. If it did, then the data would 
be sourced from there, not that the module would be redundant.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: RFC: DateTime::Format::Natural and "date_only" option

[Rick Measham]

Dave Rolsky wrote:
Actually, the current behavior just seems broken. I'd suggest that you 
should _always_ truncate to the most specific parsed value.


The current behavior is just confusing as heck in all the example up above.


Absolutely agree. Your 'date_only' is pointless .. just return to the 
precision in the parsed value.


If the input is "this time yesterday" (which would return down to the 
nanosecond) and you want the start of the hour, use 
->truncate(to=>'hour') on the result.


With strptime, I take a 'base datetime' which would give the existing 
behaviour of the Natural module .. it uses it to fill in the blanks, but 
 your module shouldn't need that.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: DateTime::Format::Strptime is not able to parse what it has formatted

[Rick Measham]

Karl Forner wrote:

Ok I figured out that I was using %G (The year corresponding to the ISO week
number) instead of %Y.
But I still thinks this is weird that the format instance is not able to
parse what it just has formatted.


Glad you worked it out.

I haven't looked, and can't be certain, but I'm guessing %G got added to 
DateTime's strftime function after I created strptime.


While I can add support for %G, it's a bit of a PITA and I doubt it's 
ever actually needed. %Y is the correct symbol for the format you're using.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: RFC:: DateTime::Span::Common

[Rick Measham]

Zefram wrote:

Terrence Brannon wrote:

Yes, I would determine that aribtrary 1 second or nanosecond based on
the data in my database tables. a MySQL BETWEEN clause includes its
endpoints.


BETWEEN, then, is not the right way to express an open or half-open
interval.  If you're going to add anything to DT::Span, add a method that
generates the correct SQL expression, taking account of the openness of
each end of the interval.

-zefram



Sounds like a job for DateTime::Format::MySQL ..

$span = DateTime::Span->from_datetimes( start => $dt1, end => $dt2 );
print DateTime::Format::MySQL->format_span( $span, 'colname' );
# colname >= '2009-04-08 23:22:00' AND colname <= '2009-04-09 23:22:00'

$span = DateTime::Span->from_datetimes( start => $dt1, before => $dt2 );
# colname >= '2009-04-08 23:22:00' AND colname < '2009-04-09 23:22:00'

$span = DateTime::Span->from_datetimes( after => $dt1, before => $dt2 );
# colname > '2009-04-08 23:22:00' AND colname < '2009-04-09 23:22:00'

$span = DateTime::Span->from_datetimes( start => $dt1 );
# colname >= '2009-04-08 23:22:00'


And could be extended to SpanSets too:
$spanset = DateTime::SpanSet->from_spans( spans => [ $dt_span, $dt_span ] );
# (colname >= '2009-04-08 23:22:00' AND colname < '2009-04-09 23:22:00') 
OR (colname >= '2009-05-08 23:22:00' AND colname < '2009-05-09 23:22:00')


(Of course, this couldn't be expected to work on infinite or even large 
spansets)


Just my $0.02.

Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: Module To Parse Format 'Friday, March 13, 2009 04:20 PM EST'

[Rick Measham]

Metz, Bobby wrote:

Jim,
You don't need to write your own module to handle these.  Just use the 
DateTime::Format::Strptime module.  Modify the parser example below with a 
pattern to suit your own format.  $dt will hold your new datetime object with 
the values parsed from your string format.

my $parser = DateTime::Format::Strptime->new(pattern => '%a %b %d %H:%M:%S %Y');
my $dt = $parser->parse_datetime($val);

See the CPAN page for all of the pattern options:

http://search.cpan.org/~rickm/DateTime-Format-Strptime-1.0900/lib/DateTime/Format/Strptime.pm


Strptime is the 'easy' answer but isn't quite correct.

Here's the example again:
Friday, March 13, 2009 04:20 PM EST

%a = Friday,
%b = March,
%d = 13,
%Y = 2009,
%I = 04,
%M = 20,
%p = pm,
%Z = EST,

So we have the pattern: "%a, %b %d, %Y %I:%M %p %Z"

HOWEVER: 'EST' is ambiguous so it won't work. Are you always in the same 
 time zone? If so, use the pattern "%a, %b %d, %Y %I:%M %p EST" and set 
the time zone explicitly.


Cheers!
Rick Measham

--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

[ANNOUNCE] DateTime::Format::Strptime 1.0900

[Rick Measham]

Available from your local CPAN archive as the mirrors pick it up. Or if 
you can't wait:

http://datetime-format-strptime.googlecode.com/files/DateTime-Format-Strptime-1.0900.tgz

This release fixes a LOT of bugs that went unnoticed (in some cases for 
couple of years! GAK!) over at RT. (Does anyone know if you can turn off 
RT for a particular distribution?)


Release notes follow.

OK on an administrative note, I'm rather embarrassed that there have 
been so many outstanding bugs for so long. Especially when it seems that 
this module is being used by so many other modules*. Anyone on the 
DateTime list interested in co-maintaining it? You'll need a google-code 
login and you should probably have already looked at the code so you 
don't pull your hair out.


* Note: If your module uses this module to parse a known format: stop 
it. This module is clunky and slow because it can parse almost anything. 
Parsing a known format is not so difficult, is it? You'll make your 
module faster if you do. And you're not left at the whim of my 
potentially broken code.


Cheers!
Rick Measham


RELEASE NOTES:

1.0900 2009-02-22
- Another pile-o-bugs
- It seems that I also wasn't seeing notifications from RT
  (please don't use it, use the Gooogle project) so all the
  following are fixed:
36672   Started failing mid May
23313   Bug handling time zones like America/New_York
2   Module dies even when on_error is 'undef'
23768   Olson timezone handling incorrect
22450   locale test failing with bleadperl
20487   nmake test_more fail (with patch); incorrect
META.yml
12071   format_datetime uses datetime locale rather than
format locale
11863   bug in DateTime::Format::Strptime 1.0601 when 
using %s

- And a couple from Google:
#8  Add DateTime::Locale to documentation
#10 Parsing bug -- can't detect word boundry after 
month abbr


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Co-maintainer of DateTime::Format::Strptime

[Rick Measham]

Steffen Mueller wrote:

Hi Greg, hi Rick,

this somehow slipped through the modu...@perl.org people's nets. I'm 
CC'ing the datetime list in case Rick's reading that.


Thanks Steffan


I'd like to be given the rights to co-maintain the
DateTime::Format::Strptime, as it has a number of bugs that are solved
in rt.cpan.org but have not been applied. I've applied some of these
locally, but would much prefer to fix it once globally and release a new
version.


G'day Greg,
The best place to discuss any DateTime module is on the DateTime list. 
From there you'd have seen I was active (and you'd have been able to 
get my personal email address).


I'll take a look at the issues on RT and get a release ready in the next 
day or so. Sorry I missed the issues .. I'm not a big fan of RT and 
you'll see the documentation says:


* Bugtracker
For bug tracking and reporting, please use the google-code tracker 
rather than the RT interface linked at search.cpan.org

http://code.google.com/p/datetime-format-strptime/issues/list

.. as does the interface at search.cpan.org and the metadata in the 
distribution. I'm not sure why people use RT when nothing points to it.


[Though to be fair I haven't seen notifications from there either and 
there are four issues listed.]


Once again, thanks for the heads-up. I'll get a release out ASAP.

(Whoever runs search.cpan .. is there any way you

Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Class::DBI::Plugin::DateTime requires DBD::Pg?

[Rick Measham]

G'day Daisuke (or anyone else helping maintain the module ..),

We've just installed your Class::DBI::Plugin::DateTime module. We're 
using it for mySQL, but it requires us to install Postgres modules. Any 
chance you can remove them from the required libs and only run the tests 
if they're installed?


DBD::Pg
DateTime::Format::Pg

Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Letting users select timezone

[Rick Measham]

David Cantrell wrote:

Tatsuhiko Miyagawa wrote:


You can get the user's country ... from Accept-Language HTTP header


No you can't.  I prefer to use English (specifically en-gb) whether I'm 
in the UK, Germany or Japan.  Even if I were to move to Japan 
permanently, I'd still prefer to use English, and so leave that header 
set to en-gb, but would also like sites to know that I'm in the 
Asia/Tokyo timezone.


A better method would be to find all the time zones with the same offset 
as the user. You can get this offset from javascript if you're using a 
web interface. What you don't have is a list of current offsets, so 
you'd have to load each and every time zone module to get its offset. 
Not fast and not cheap.


I'd consider
a) Get a list of time zones that are currently in use (ie, they didn't 
stop in 1982 .. this might be all of them, I can't remember)
b) Create a hash of arrays where the key is the offset (all offsets for 
the TZ .. DST and non-DST)

   eg: ( 1100 => [ 'Australia/Melbourne', 'Australia/Sydney' ... ] )
c) Store that somewhere.

Now when you get an offset of 1100, you have a LOT smaller list of 
possible TZs. Present that list to the user. Along with a button to 
'show all time zones'.


Cheers!
Rick Measham



--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: DateTime::Lite

[Rick Measham]

Tatsuhiko Miyagawa wrote:

It'll be
extremely useful if we can start writing code with DateTime and later
replace the 'use' line with DateTime::Lite, or start writing with
DateTime::Lite and later "upgrade" to DateTime when we need more
complex stuff like Set or Calendar APIs.


This module seems to be a nice fit between my DateTime::Lazy and 
full-blown DateTime. To that end, it would be nice if there was a 
->to_datetime method that returned the same datetime as a DateTime object.


Cheers!
Rick Measham

--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: definition of correctness

[Rick Measham]

bharanee rathna wrote:

although the latter seems consistent with what POSIX::mktime does. The
question I have is about the correctness of DST calculations and
whether POSIX::mktime is busted.


I'm not sure what you're thinking might be busted here. If we're doing 
the same as POSIX::mktime does, then it's doing it right.


When you add a day, you expect the wallclock to stay the same. "Tune in 
the same time tomorrow".


When you add 24 hours, you expect 24 *HOURS* to elapse -- no matter how 
many hours there are in a day.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: new DateTime::Format module

[Rick Measham]

Dave Rolsky wrote:
This all seems like it could go into DT::F::Duration though, just with 
different strftime-type specifiers (or CLDR, or whatever).


Absolutely it could and should. %c and %x and %X would be the obvious 
first candidates along with the alternate %{...} format for other CLDR 
formats.


Dan, please consider working at extending DateTime::Locale to include 
the duration formats and then working at helping me to extend 
DateTime::Format::Duration to make use of that data.


Alternately, once CLDR duration locales are imported into 
DateTime::Locale, write a module named something like 
DateTime::Format::Duration::Locale that makes use of the data.


The normalisation functions in DateTime::Format::Duration give it its 
real power so I would suggest you wrap the _as_deltas methods in 
whatever you decide to do.


Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: Seconds left in day + DST

[Rick Measham]

P DD wrote:

my $tom = ($now + DateTime::Duration->new(days => 1))->truncate(to =>
'day');


Can I suggest this for neater code:
my $tom = $dt->clone->add( days => 1 )->truncate( to => 'day' );

Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: ANNOUNCE: DateTime::Locale 0.40 and DateTime 0.43

[Rick Measham]

Dave Rolsky wrote:

However, it will break DateTime::Format::Strptime, apparently.

Paging Rick Measham ;)


Thanks for the work with Locales Dave, great to get all the available 
data in there.


I'll look at strptime in the next couple of days unless someone submits 
a patch earlier :-D


Cheers!
Rick Measham

--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: [rt.cpan.org #34912] Constants for months/weekdays?

[Rick Measham]

Flavio S. Glock wrote:

# implementation using the "ICal" module
# implementation using the "Recurrence" module


Sure, those work. But to quote the journal:
"Instead you are apparently expected to copy-paste some slightly fiddly 
code from an FAQ and tweak it."


I think the code in the blog post has merit, though the wrong module 
name and therefore, the wrong API


I've taken the code in Aristotle's journal post, fixed it up a bit, 
wrapped it all in a DateTime::Event API and attached it. There's no 
tests yet, just the module.


Thoughts and comments are, as always, most welcome.

Aristotle: I'm happy to hand this module over to you if you want to put 
it on CPAN and maintain it, otherwise I will.


Cheers!
Rick Measham

--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au




DayOfWeek.pm
Description: Perl program


examples.pl
Description: Perl program

Re: ANNOUNCE: DateTime::TimeZone 0.74

[Rick Measham]

Dave Rolsky wrote:

  Iraq


Oh, finally some good news from Iraq! They've abandoned DST!

Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: Determining current abbreviations for timezones for difference timezones all over the world

[Rick Measham]

William Heath wrote:
> I need to list the timezone abbreviation.  For example:
>
> America/New_York  EDT or EST depending on if it is DST
> America/Los_Angeles  PST or PDT depending on if it is DST
>
> Is there some way for me to determine these for the timezones?

As I said:
> EST is
> (1) ambiguous (there's an EST in both America and Australia)
> (2) a 'standard' time (the 's') not a summer or daylight time
> and so the offset wont ever change
> (3) historically un-mappable to any 'proper' time zone as they
> keep changing by civil decree in various jurisdictions

However, if you had checked the DateTime documentation and you'd find 
"time_zone_short_name" under "Get Methods" at 
http://search.cpan.org/~drolsky/DateTime-0.42/lib/DateTime.pm#%22Get%22_Methods


Note, again however, the caveats on the DT:TZ method 
(http://search.cpan.org/~drolsky/DateTime-TimeZone-0.73/lib/DateTime/TimeZone.pm#$tz-%3Eshort_name_for_datetime(_$dt_))


> Given a DateTime object, this method returns the "short name" for the 
current observance and rule this datetime is in. These are names like 
"EST", "GMT", etc.

>
> It is strongly recommended that you do not rely on these names for 
anything other than display. These names are not official, and many of 
them are simply the invention of the Olson database maintainers. 
Moreover, these names are not unique. For example, there is an "EST" at 
both -0500 and +1000/+1100.


William Heath wrote:
> I love perl and the DateTime module!

It's OK, you don't have to keep reassuring us!

Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: namespace DateTime::BusinessHours

[Rick Measham]

Antano Solar wrote:

I was anyways wanting to do a rewrite of the module with also a bug fix that
I encountered.


Take a look at the thread from back on Jan 22 entitled "Sets, 
Recurrences, Public Holidays .. Business Days trouble"


I'm basically solving the same case as you using sets and recurrences 
(and using iCal for subtracting public holidays)


As I'm just needing short runs of days, I'm just looping over the 
$business_days->iterator $days times and then using the final resulting $dt.


(NOTE for other DT devs: It would be good if, given a DateTime::Set (or 
DateTime::Set::ICal) you could get the $Nth day .. like the 10th day. 
rather than an iterator and call it $N times or turning the set into a 
list (which in this case is infinite))


Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Daylight savings time timezone conversion automatically?

[Rick Measham]

William Heath wrote:

I think I figured it out, what is important to understand is that you
can't choose EST, you must choose a country/city for the function to
adjust for DST automatically.  My question was probably too simple for
you to give me this solution but I did figure it out.  Does that make
sense to you?


Absolutely. The time zones supported by DateTime are designed to be 
robust, not only for today but back to 1970.


EST is
(1) ambiguous (there's an EST in both America and Australia)
(2) a 'standard' time (the 's') not a summer or daylight time
and so the offset wont ever change
(3) historically un-mappable to any 'proper' time zone as they
keep changing by civil decree in various jurisdictions

Cheers!
Rick Measham
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: Daylight savings time timezone conversion automatically?

[Rick Measham]

William Heath wrote:

The
trouble is I need to find the GMT offset for a timezone and I don't
know how to do this correctly for daylight saving time. 


my $dt = new DateTime(
year => 2008,
month => 3,
day   => 12,
hour  => 16,
time_zone => 'Australia/Melbourne'
);

print $dt->offset; # in seconds
# 39600

printf( "%s%02d%02d",
$dt->offset >= 0 ? '+' : '-',
int($dt->offset / 60 / 60),
($dt->offset / 60) % 60
);
# +1100
--
Message  protected for iSite by MailGuard: e-mail anti-virus, anti-spam and 
content filtering.
http://www.mailguard.com.au

Re: DateTime->season?

[Rick Measham]

David E. Wheeler wrote:

Hey All,

Someone on the Bricolage list needed a season method, so I whipped up 
this ugly one:


sub season {
my $date = shift->strftime('%m-%d');
return $date lt '03-21' ? 'winter'
 : $date lt '06-21' ? 'spring'
 : $date lt '09-21' ? 'summer'
 : $date lt '12-21' ? 'autumn'
 :'winter';
}

Since seasons can sometimes change on the 22nd instead of the 21st, this 
isn't quite right. Anyone else done something like this but more accurate?


Where in the world do you want to calculate them?

http://en.wikipedia.org/wiki/Season#Reckoning seems to have the 
information you need.


Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Sets, Recurrences, Public Holidays .. Business Days trouble

[Rick Measham]

The aim is to work out N 'business days' from now.

Every one defines business days differently, but for me it's Monday to 
Friday skipping public holidays.


Step 1: Set of every day
Step 2: Complemented with weekends
Step 3: Complemented with public holidays

However, the code I've put together dies in rather nasty ways or runs 
really slowly (change the @events in the grep to @events[1,2])


If we forget about holidays, then it's nice and fast (though I'd prefer 
not to have to interate ...)


I'm guessing the speed decrease is due to the recurrence getting random 
holes (the public holidays) means we need to enumerate the entire set.


But for now, if someone could take a look at the code and see if you can 
work out why it dies, it would be much appreciated.


(note that $events[6] is the 28th of January and so it should be skipped 
.. but if you include '6' in the @events slice, you end up with it 
dieing on day 9)


Cheers!
Rick Measham


business_days.pl
Description: Perl program


smime.p7s
Description: S/MIME Cryptographic Signature

Re: New Module - DateTime::NaturalLanguage

[Rick Measham]

Luke Hutscal wrote:

I am not quite sure that I explained my module very clearly - it doesn't
really do anything with DateTime objects in particular -


Ahh, that's the rub. The DateTime::* namespace is for modules that 
interact with DateTime objects.


Maybe you could look at putting it in Date:: or Time:: or TimeDate:: ?

Cheers!
Rick Measham

Daylight-Saving Causes Twin Arrival Pickle

[Rick Measham]

http://www.wral.com/news/local/story/2011296/

Thought my fellow datetime nerds would get a laugh out of this story.

Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Re: REQ: Additional 'truncate' option

[Rick Measham]

Zefram wrote:

That doesn't do what was requested: if you start with a Sunday then it
moves a week back rather than just going to the beginning of the day.
But this will work:

$dt->add( days => 1 )->truncate( to => 'week' )->subtract( days => 1 );


Ahhh! I knew there was something more complex to it! Thanks Zefram, that 
fixes the problem I had with the task originally.


Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Re: REQ: Additional 'truncate' option

[Rick Measham]

Dave Rolsky wrote:

I see it's use, but it's really easy to do already:
 $dt->truncate( to => 'week' )->subtract( days => 1 );


Ahh crap!

All it takes is another set of eyes. My code to do it belongs on the 
daily-wtf!


Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [rt.cpan.org #23307] YYYY-MM-DD HH:MM:SS not a valid datetime

[Rick Measham]

Joshua Hoblitt wrote:

I would be tempted to make a parser for this RFC live in a new
namespace, e.g.  DateTime::Format::RFC3339, regardless of how much code
(and tests) are shared.  It probably makes sense to bundle it with
DT:F::ISO8601 as well.


Interestingly, I was going to point the list to the W3C spec that is 
basically the same format, just less formally defined: 
http://www.w3.org/TR/NOTE-datetime


I most certainly think it should be its own Format module so that the 
parser can die on a valid ISO8601 date that is invalid in RFC3339


Writing the module would not be a problem for any experienced DateTimer.

I don't think it makes sense to bundle it with ISO8601 as it's only 
relationship is that it happens to be a subset of the ISO8601 rules. It 
is it's own format, and I'd prefer to have it in its own distribution in 
order to make it clear that it is a valid, independent, format.


Cheers!
Rick Measham

Re: [rt.cpan.org #29330] 004_locale_defaults test failing

[Rick Measham]

 via RT wrote:

   Queue: DateTime-Format-Strptime
 Subject: 004_locale_defaults test failing
 Ticket http://rt.cpan.org/Ticket/Display.html?id=29330 >


The 004_locale_defaults.t failed during make test. This is also
happening for the CPAN::Reporter tests like this link:
http://www.nntp.perl.org/group/perl.cpan.testers/2007/09/msg623300.html.

Anyway, I found that I got the same error as reported at the url above
and it had to do with the French locale dates on lines 31-37. Disabling
these made the tests pass.


I've been getting a pile of reports about these tests breaking. Did 
something change in the latest Locale release that affects the French 
information? (Possibly other stuff too, I just test the French)


Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

REQ: Additional 'truncate' option

[Rick Measham]

Is there any chance we can have ->truncate( to => 'Sunday' ) for 
truncating to week-beginning-on-sunday?


Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [rt.cpan.org #28075] missing prereq DateTime::Helpers

[Rick Measham]

Martin Thurn via RT wrote:

Tue Jul 10 00:18:37 2007: Request 28075 was acted upon.
Transaction: Ticket created by MTHURN
   Queue: DateTime-Format-Strptime
 Subject: missing prereq DateTime::Helpers
   Broken in: 1.0700
Severity: Important
   Owner: Nobody
  Requestors: [EMAIL PROTECTED]
  Status: new
 Ticket http://rt.cpan.org/Ticket/Display.html?id=28075 >


Please add DateTime::Helpers as a PREREQ in your Makefile.PL

t/001_load...
#   Failed test 'use DateTime::Format::Strptime;'
#   at t/001_load.t line 7.
# Tried to use 'DateTime::Format::Strptime'.
# Error:  Can't locate DateTime/Helpers.pm in @INC (@INC contains:


Erm .. WTF is DateTime::Helpers?

.. and what does it have to do with DateTime::Format::Strptime?

Cheers!
Rick Measham


smime.p7s
Description: S/MIME Cryptographic Signature

Re: DateTime::Format::Duration tests failed: Found out why.

[Rick Measham]

Björn Tackmann wrote:
some days ago I wrote you an e-mail stating that some tests for 
DateTime::Format::Duration failed. Today, I spent some more time on 
looking for the reason. The good news is: your module does not seem to 
be flawed :)


hahah .. thanks Björn .. telling me that gave me the impetus to finally
get it fixed. However by the time I finished, I decided that it wasn't
all just bad tests.

For the first test, I'd agree that the test itself is incorrect:
# Test 41 -- the second day has 25 hours
['-00-00 48:00:00', '-00-01 23:00:00', 'DST ends, Day is 25
hours long'],

Should be:
['-00-00 48:00:00', '-00-01 24:00:00', 'DST ends, Day is 25
hours long'],

However going the rest I don't agree that it's just a case of fixing the
tests and so I've refactored the code.

Look for 1.03 on a CPAN mirror near you shortly.

Cheers!
Rick Measham














smime.p7s
Description: S/MIME Cryptographic Signature

Re: instance data for DateTime derived classes

[Rick Measham]

Boorstein, Daniel B wrote:

I realize this is my problem since I broke encapsulation, but I'm
wondering if others have dealt with this already. Is there a designated
means for derived classes to add custom instance data? I've perused the
docs, but didn't see anything specific for authors of derived classes.


There's been a few times where I wanted to hang data off a DT, 
especially for DT::Event modules


I'd suggest we have a purpose built $self->{data} for hanging such stuff 
and make sure that anything in there is preserved across mutations and 
clonings.


There was talk ages ago about life span controls however:

  $dt = $easter;

  print $dt->{data}{EventName};
  # Easter Sunday

  $dt->add( days => 4 );

  print $dt->{data}{EventName};
  # Easter Sunday

So now it's incorrect. Four days after Easter isn't Easter any more, so 
the EventName shouldn't survive any 'add' that takes it past midnight, 
but it should survive any 'add' that leaves it still on the same 'day'


How do you do that?
* One option is to ignore such things and just leave the data hanging 
around. If someone changes the date, it's their own damned fault.
* Another option would be a callback class method and use 
$self->{data}{callback} to store an arrayref of packages that want a 
callback on any mutation:


sub add_duration {
  ...
  ...
  foreach( @{ $self->{data}{callback} } ){
$_->callback( $self );
  }
}

Then in DateTime::Event::Easter, there's a sub callback that checks the 
data in the object and adjusts, deletes etc., as appropriate


print Dumper($dt->{data});
# { callback => [ 'DateTime::Event::Easter' ], initial_date => 
'2007-04-08', event_name => 'Easter Sunday' }


package DateTime::Event::Easter;
sub callback {
if ($dt->ymd('-') ne $dt->{data}{initial_date}){
delete $dt->{data}{initial_date};
delete $dt->{data}{event_name};
$dt->{data}{callback} = [
grep { $_ ne 'DateTime::Format::Easter' }
@{$dt->{data}{callback}}
];
}
}

__END__

Just a thought on how we can do such things.

Cheers!
Rick Measham

Re: DateTime::Format::MySQL supporting time zones

[Rick Measham]

Dave Rolsky wrote:
I tend to not favor this sort of API, because it's basically a global. 
That means that if two CPAN modules both set it, the last one to call 
this method wins. It also doesn't play nice with mod_perl, where you may 
be running multiple apps under one persistent interpreter.


Many (some?) of the other format modules let you create a format object 
and then call the parse_datetime method on that object. This is 
specifically so you can set options that don't become globals.


Eg:

my $parser = new DateTime::Format::MySQL(
time_zone => "UTC"
);

my $dt = $parser->parse_datetime( $db_data );

print $dt->time_zone->name;
# UTC

It would be fairly easy for Nick to look at the way other Format modules 
do it and submit a patch for DT:F:MySQL to do this...


Cheers!
Rick Measham

DateTime::Event::DST (Pulling DST changes from DateTime)

[Rick Measham]

Back in October 2003, I wrote DateTime::Event::DST for exactly this purpose:

http://marc.theaimsgroup.com/?l=perl-datetime&m=106716694406817&w=2

It never got anywhere for some reason. I'd think that as DST changes are 
an event, they should be a DT:E module.


The code is in the archive if anyone wants to resurrect it. No idea how 
it worked or if it still works.


Cheers!
Rick Measham

Re: syntax to specify time scales

[Rick Measham]

Zefram wrote:

Rick Measham wrote:

my $riyadh_lmt = DateTime::TimeZone::LMT->new(
   longitude => 46 + (43 / 60) + (27 / 3600)
);


How much error in time conversions is introduced by the floating point
rounding?


DateTime allows for a one-second precision in the offset, so while LMT 
passes a floating number of seconds, DateTime will only use a whole 
number of seconds. Fix that and LMT will be work with it :)


Cheers!
Rick Measham

Re: syntax to specify time scales

[Rick Measham]

Eugene van der Pijll wrote:

If I were to implement these time scales for DateTime, I would probably
implement them as subclasses of UT1 (or "LMT") and LAT, with the
geographical longitude as parameter; "LMT+46d43m27s" for Riyadh legal
time, for example. But your notation is reasonable as well.


DateTime::TimeZone::LMT already exists .. though without the ability to 
set the longitude via stringification


my $riyadh_lmt = DateTime::TimeZone::LMT->new(
longitude => 46 + (43 / 60) + (27 / 3600)
);

$now = DateTime->now( time_zone => $riyadh_lmt );

A thought: it might be good to somehow include the ability to load other 
TZ modules from a string. Eg. time_zone => "LMT/46d43m27s" would look 
for LMT/46d43m27s.pm and failing that, drop back to looking for LMT.pm 
and pass it's constructor the '46d43m27s'.


Cheers!
Rick Measham

Re: recurring system

[Rick Measham]

Matthew wrote:

Hey guys,
  Does anyone have, already made, some type of "recurring events" 
module? We have our in-house function that works with singular weekly 
and singular monthly events but we'd like to branch into daily, 
bi-daily, bi-weekly, bi-monthly, every X weeks, every X days, etc.


Like DateTime::Event::Recurrence?

my $bi_daily_at_10_30am_set = DateTime::Event::Recurrence->daily(
   interval => 2,
   hours => 10,
   minutes => 30
);

http://search.cpan.org/dist/DateTime-Event-Recurrence/lib/DateTime/Event/Recurrence.pm

Cheers!
Rick Measham

Re: simple calculation frustrations

[Rick Measham]

Matthew wrote:

Alternately, use DateTime:


  I tried to do so. The problem is that the date's are stored in the 
users local timezone and we only store the offset from GMT. (ex: -6 or 7)


  Is there some array or table I can use to convert '-6' to something 
DateTime:: can use?


Epochs are UTC on most systems, so you're probably storing them as UTC ..

-6 is meaningless and so useless for DST calculations.

Last week Melbourne, Sydney and Brisbane were all +1000. Now Melbourne 
and Sydney are +1100, but Brisbane is still +1000. And Hobart switched 
from +1000 to +1100 a few weeks earlier.


Unless you have more information that '-6' then you'll never be able to 
properly convert across a DST change.


You could, of course, continue to use the UTC time zone. But you still 
can't properly turn that into the user's local time zone as it's no 
longer -6, but -7 or some such.


Cheers!
Rick Measham

Re: simple calculation frustrations

[Rick Measham]

Matthew wrote:

hey guys,
  I can't believe I'm having this much trouble doing this. I'm pulling a 
UNIX_TIMESTAMP from MySQL and all I want to do is add a certain interval 
to that date then spit out the new date. Right now we only support 
weekly intervals in our app.


Best bet: Get mysql to add the week, providing it's time zone is set 
correctly ..


SELECT UNIX_TIMESTAMP( FROM_UNIXTIME( theField ) + INTERVAL 7 DAY )

(You're supposed to be able to do 1 WEEK too, but I can't get that to 
work in 4.1)


Alternately, use DateTime:

use DateTime;
my $dt = DateTime->from_epoch(
epoch => $eventDate,
# So that DST is accounted for:
time_zone => 'Australia/Melbourne',
);
$dt->add( weeks => 1 );
$dt->epoch ==
(1 week after the $eventDate expressed as an epoch)

Cheers!
Rick Measham

Re: ANNOUNCE: DateTime::TimeZone 0.54

[Rick Measham]

Dave Rolsky wrote:

0.54 2006-10-25


I wonder if DT::TZ shouldn't have a dual-versioning system .. I guess 
the $VERSION is sequential as per currently, but the distro should 
indicate the Olson version. That way you can quickly see that the Olson 
has increased.


DateTime-TimeZone-2006n.0.54

Just a thought .. not really too important

Cheers!
Rick Measham

Re: inconsistent round trip in Date::Parse (Date::Format)

[Rick Measham]

Jim W. Jones wrote:

The date and time info from the portal log file
looks like this: Mon Aug 3, 2006 3:45 AM  (no seconds)

I Perl-ed it into:Mon, 3 Aug 2006 3:45:00 GMT
which is one of the formats which  str2time is supposed to parse.

...

As a check, I immediately round-tripped this through time2str,
and got an inconsistent day-of-week:  Thu Aug 3 03:45:00 GMT 2006

What have I missed???  Do I have fighting use-statements?


You have bad input data. My calendar shows that August 3rd, 2006 was a 
Thursday, not a Monday.


Cheers!
Rick Measham

Re: low-level date modules

[Rick Measham]

Zefram wrote:

Rick Measham wrote:
I'm still trying to convince people that you can't just add 24*60*60 to 
time() to add a day ..


That's one of the things you *can* do, unless you're starting in a leap
second (in which case time() is ambiguous).  time() increases exactly
86400 per UTC day, regardless of day length.


Sorry .. should have pointed out that they want to do it in local .. we 
fight an uphill battle to get people to use UTC ... erm .. and if you're 
fussed about DT not implementing future leap seconds how can you be 
happy with adding 86400 seconds for a day (even in UTC) when leapseconds 
make it ambiguous?


Cheers!
Rick Measham

Re: low-level date modules

[Rick Measham]

Eugene van der Pijll wrote:

We should not perhaps be calling our time scale
"utc"; but that would again be hard to explain to ordinary users.


I'm still trying to convince people that you can't just add 24*60*60 to 
time() to add a day ..


Cheers!
Rick Measham

Re: %p in DateTime::Format::Strptime doesn't match "PM"

[Rick Measham]

Mike Schilli wrote:

Maybe "%H matched a 24-hour value in the AM range, which conflicts
with the %p value found (PM). Use %I for 12-hour values." would be
easier to understand for the impatient reader :).


Sure .. I can do that .. though it won't specify %H .. more like: The 
hour value is in 24-hour time, however the value specified (1) does not 
match the am/pm value (pm)

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content 
filtering.
http://www.mailguard.com.au

Re: %p in DateTime::Format::Strptime doesn't match "PM"

[Rick Measham]

Mike Schilli wrote:

Looks like the %p in the Strptime snippet below doesn't match the "PM"
in the date string. Anyone knows why?


To work out the 'why', check $p->errmsg:
Your am/pm value (PM) does not match your hour (01)

So your am/pm value of 'PM' doesn't match the hour 01 as 01 is in the 
morning. To hand it to you on a platter, you're using the %H specifier 
in your pattern which is the 24-hour specifier rather than %I which is 
the 12 hour specifier.


Cheers!
Rick Measham

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content 
filtering.
http://www.mailguard.com.au

Re: New DateTime::Format::* module

[Rick Measham]

Peter Conrey wrote:

I have written a new module that simply parses dates in several different
formats. The reason I have written this on is that every existing parser from
this project that I've tried has fallen short in one area or another,
particularly in parsing our most commonly used format, "MM/dd/".


I've some glue that I've called "DateTime::Format::TimeParseDate" that 
glues Time::ParseDate to DateTime. I love it because it normally 
does-what-you-mean to the point of understanding "Yesterday at 2pm" or 
"Midnight next Wednesday".


I haven't released it because it isn't documented at all and I've not 
written any tests. I've attached it in case it helps.


Cheers!
Rick Measham
package DateTime::Format::TimeParseDate;

use strict;
use warnings;

use DateTime;
use Time::ParseDate qw//;
use Params::Validate qw/validate BOOLEAN/;

sub parse_datetime {
	my $class = shift;
	my $date  = shift;

	my %inarg = @_;
	my %arg;
	foreach ( keys %inarg ) {
		$arg{ uc( $_ ) } = $inarg{ $_ };
	}

	my $epoch = Time::ParseDate::parsedate( $date, %arg );

	my $dt = DateTime->from_epoch(epoch => $epoch);

	if ($arg{TZ}) {
		$dt->set_time_zone( $arg{TZ} );
	}
	return $dt;
}
#print STDERR "Loaded DateTime::Format::TimeParseDate 0.0001_01";
1;

Re: DT::Format::Strptime %H

[Rick Measham]

Jerrad Pierce wrote:

I've run into a bit a bit of a problem using a format containing %H with raw
data. The data I have uses both 0:00 and 24:00, one being the beginning of the
day, the other the end. I know that the docs state %H accepts 0-23, but it
doesn't seem unreasonable that it ought to DWIM, and process 24:00 as the
beginning of the next day... instead of forcing the handling upon the user
(which defeats the purpose of comprehensive magic modules for complex tasks ;-)


Nothing to do with strptime .. no DateTime method allows overflowing of 
parameters. Check the archives for much discussion. If you need it, 
consider writing DateTime::Format::Overflow or similar.


Cheers!
Rick Measham

[ANNOUNCE] DateTime::LazyInit 1.0200

[Rick Measham]

Sorry this has taken so long to release .. kinda forgot it was sitting 
there...


There's a few doc errors (errors I missed last time too ..) including 
spelling Philip's name completely wrong. Sorry mate! I'll fix these 
errors in a new release later this week that, unless anyone finds other 
holes, will just be a doc-fix release: 1.0101


From the Changes .. note that while the main version number has 
increased, the API is stable.


1.0100 2006-05-13
- Version number fix
- Moved to version 1.0100 in line with my other modules and the
  above versioning schema. No actual code release. API did not
  change.

1.0200 2006-05-13
- New Constructors
- Phillip Garrott provided patches to implement other
  constructors and overloading of various things in line
  with DT.

Re: DateTime module and epoch time

[Rick Measham]

Lenny Rachitsky wrote:

I'm trying to improve the performance of some code, and I've found that a
lot of the inefficiencies I have are caused by a large number of DateTime
object creations.


Do you use every one of these DateTime objects, or are you just creating 
them all and only using some? If you're only using some of them, have a 
look at DateTime::LazyInit (which reminds me, I need to release the new 
version huh?)


Cheers!
Rick Measham

DateTime::Format::Duration update

[Rick Measham]

There's been a few comments and questions regarding 
DateTime::Format::Duration.


1. I'm looking at it
2. If you ignore any failures from the normalisation tests and
   don't use local normalisation, you should be fine. (ISO
   normalisation is fine)
3. DateTime Math is confusing me more than ever (not the
   implementation, the logic)

Once I sort all that out, there'll be a working release.

Here's some logic from my brain:

DST_DT := day before end of DST
a) DST_DT + 2 days   = 2 days
   (only the 'day' should change, so we're now 49 hours later)
b) DST_DT + 48 hours = 1 day, 24 hours
   (as there's 25 hours in the next day)
c) DST_DT + 2 days - 48 hours = 1 hour
   (2 days = 49 hrs as per (a) above)

However I can't get it to work like that using DateTime's own maths so 
I'm either looking for an explaination as to what's wrong with my logic, 
or I'm going to re-implement the math-as-I-need-it in DT:F:D as I'm 
losing too much hair over this!


Cheers!
Rick Measham

Re: from_epoch for DateTime::LazyInit?

[Rick Measham]

Garrett, Philip (MAN-Corporate) wrote:

I'm just trying to make the DT::LI object act like a DT.  Isn't that the idea?


The idea is to allow quick creation of DT objects .. mainly for the 
purpose of creating thousands of DT object that lazily inflate to 
full-blown DateTime objects. It would be good to transparently inflate 
everything, but I'm not going to do that at the expense of adding overloads.


To help with this, the next release will have inflate() rather than 
__inflate() in order to allow deliberate inflation without feeling like 
you're messing with internals.


I think it will also allow you to add a Class name to inflate() so that 
you can use your subclassing ..


print ref $dtLI;
# DateTime::LazyInit;

$dtLI->inflate('yourClass');

print ref $dtLI;
# yourClass

Cheers!
Rick Measham

P.S. if you want to run benchmarking on the overloading, and it shows 
that it doesn't increase load or creation time(span) of DT:LI objects 
I'm willing to reconsider, but I'm a bit loathe :)

Re: from_epoch for DateTime::LazyInit?

[Rick Measham]

Garrett, Philip (MAN-Corporate) wrote:

I also had trouble with the lazyinit module not supporting overloaded
operators, e.g. $dt1 > $dt2.

To fix, I added this to the main LazyInit package. Using the method
names as strings didn't work -- I guess overload doesn't like AUTOLOAD.

use overload ( 'fallback' => 1,
   '<=>' => sub { shift->_compare_overload(@_) },


We're really getting way beyond the scope of DT::LI here .. it's 
supposed to be completely simple front-end to creating unvalidated 
DateTime objects.


If you want to do comparisons, use the real functions rather than the 
overloads, or create full DateTime objects.


Cheers!
Rick Measham

Re: from_epoch for DateTime::LazyInit?

[Rick Measham]

Garrett, Philip (MAN-Corporate) wrote:

Whoops, the patch I sent earlier is botched. This one should be better.
One thing I forgot was to update the POD -- I'll try to get that later.


Thanks Philip,
I'd already noticed it wasn't working and fixed it .. :)


I also added an overloadable class method __datetime_class() so that if
you want to use a subclass of DateTime (as I do) then you can.


I'm not sure I want to do this .. we don't do this sort of thing in any 
other DateTime module (afaik) so until we work out if/how we want to do 
it then I'm a little loathe to include it.


Unless Dave and the rest of the DateTime team want to chime in, I'd just 
suggest you overload the whole __inflate() routine.


Cheers!
Rick Measham

Re: from_epoch for DateTime::LazyInit?

[Rick Measham]

Garrett, Philip (MAN-Corporate) wrote:

Are there any plans to add a from_epoch constructor for
DateTime::LazyInit?  The module looks really useful for me, but since I
create almost all my DateTime objects from epoch times, I can't use it.


No plans at all .. but if you provide a patch that looks like it will 
fit within the goals of LI, I'll have a look.


Cheers!
Rick Measham

Re: Australia daylight savings extended in 2006

[Rick Measham]

Mike Schilli wrote:

Is DateTime ready for this?

http://support.microsoft.com/?id=909915
http://ftp.support.compaq.com.au/


Sure is. Here's the relevent Olson rules[1]:

RuleAV  19911994-   Mar Sun>=1  2:00s   0   -
RuleAV  19952005-   Mar lastSun 2:00s   0   -
RuleAV  2006only-   Apr Sun>=1  2:00s   0   -
RuleAV  2007max -   Mar lastSun 2:00s   0   -


From 1991 to 1994 we changed back on the Sunday that was 
greater-or-equal to the first of March


In 1995 until 2005 we moved it later and changed back on the last Sunday 
in March


In 2006 and only 2005, we're moving back on the Sunday that is 
greater-or-equal to the first of April


Then from 2007 onwards we're back to the last Sunday in March

Cheers!
Rick Measham


[1] ftp://elsie.nci.nih.gov/pub/tzdata2006a.tar.gz
Then check 'australasia'

--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: Daylight Saving

[Rick Measham]

Dave Rolsky wrote:
This could get pretty tricky. You'd really want GIS-type support for 
storing the borders of a time zone.


yeah, guess so .. was thinking along the lines of eastern somestate is 
Ameria/SomeCity and western somestate is America/AnotherCity. You know 
the divide is somewhere around N degrees longitude so everything 100 
miles to the west of the line gets America/AnotherCity and everything 
100 miles to the east gets America/SomeCity. That leaves you with a 200 
mile section that you'd need to sort for yourself.


Of course, it's never that easy is it?

Cheers!
Rick Measham


--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: Daylight Saving

[Rick Measham]

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?


Bill Moseley then wrote:

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?


As you say, you don't know *when* the DST is in effect. I'm not sure 
about the US, but two here, given PostCode 3030, the first '3' indicates 
Victoria. There's only one TZ in Victoria therefore I can map any 
postcode starting with a 3 to Australia/Melbourne


Does the US ever have more than one TZ per state? As you have the state 
information, it wouldn't be hard to get a hash of states -> Olson Time 
Zone names. If you have more than one TZ per state, I'd have to assume 
its rare and so you could do those states by hand (painful I know, but I 
imagine there's a ZIP <-> lat/lon table around that would help you 
divide the state into positive regions 
(http://www.zipinfo.com/search/zipcode.htm). After that you can hand-cut 
those along the edges of those regions.


Just a few thoughts

Cheers!
Rick Measham

--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: Australia daylight savings extended in 2006

[Rick Measham]

John Peacock wrote:
There are a *lot* of applications (not just M$loth's brood) which rely 
on governments not doing stupid things like this.


Hey! That's my government you're talking about there! (Australia/Melbourne)

Seriously though, were I not married I would have insisted on keeping 
all my clocks at the normal changeover, however my wife is a teacher and 
her being an hour out of synch with the school would probably not go 
down too well.


That being said, the other stupid thing they're doing is shortening the 
first term at school .. normally we have 4 terms of apx 10 weeks. The 
first term normally takes a little while to get into the swing: the 
students have new subjects, there's camps and photos and a myriad of 
administration matters. Now our ever-wise government has decided that 
because of these 'Commonwealth Games', term one will only have six 
weeks. So give the students a month to get down to work and you've now 
only got two weeks left!


Personally, I say get rid of DST everywhere. Let the Government (capital 
'G' .. in a democracy that's the people) decide what UTC offset we'd 
prefer to be rather than basing it on anything else like the sun 
posiiton which we know changes. Most people I talk to here would prefer 
it to be 'Permanent Daylight Savings' we Melbourne would be UTC+1100 
every day of the year.




Cheers!
Rick Measham

--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: setting an object using datetime string?

[Rick Measham]

Danny Brian wrote:
I promise I've browsed docs, FAQs, and the list archives, but I  simply 
can't determine whether or not DateTime provides a way to set  a time 
using an ISO 8601 string (the same thing output by $dt- >datetime()) 
without going through DateTime::Format::Strptime.


DateTime::Format::ISO8601 rather than Strptime

Cheers!
Rick Measham


--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: DateTime::Duration Presentation

[Rick Measham]

David Wheeler wrote:
The normalization stuff in DateTime::Format::Duration gets us part of  
the way there, but not quite, as if I say, "23 hours, 90 minutes", it  
will return "24 hours 29 minutes", which is not quite the same as  what 
was initially specified.


That's probably as close as you can get ..

At any rate, does this make sense to folks? If so, I'd be willing to  
hack something into DateTime::Duration to support this. Comments?


The problem with this is that you'd really want to use something other 
than DateTime::Duration as DT:D is designed for Date math.


 DT:DProposal
(11 hours, 90 minutes)   750m11h 90m
+
(32 minutes)  32m32m
=
 782m   11h 122m
* 2 1564m   22h 244m

...

The more we do, the more confusing your proposed method gets. Sure you 
could keep it separate inside DT:D but then you'll have to do the math 
for both the current and the proposed values every time.


I'd be thinking of just storing the values as a hash(ref) that you later 
feed back into DT:D when you need to. That way you can store it however 
you need to.


(Personally, I'd be happy as a user if I asked for 90m if it returned 
1h30m .. but I imagine different things need different units)


Cheers!
Rick Measham

Re: Comparing DateTime::Duration

[Rick Measham]

David Wheeler wrote:
But all I'm really interested in is whether the  
Duration object has a different duration than another object. IOW,  are 
they identical to each other? The time that they're assigned to  is not 
really relevant to me.


The time they're assigned to is *always* relevent for testing 
'equality'. One month from now will be Feb 7th. 31 days from now will be 
Feb 7th. So from now, they're equal. However 1 month from Feb 7th will 
be March 7th whereas 31 days from Feb 7th will be March 10th.


Now, if perl had an '===' operator for 'identical' then we could use 
that to determine if both durations are *always* equal (so maybe we need 
to add a comparison function for it:


1 second === 10 nanoseconds
1 year   === 12 months
N units  === N units

I'm happy to work on a patch if people want to see this functionality?

Cheers!
Rick Measham

--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: Date range from Week number

[Rick Measham]

On Wed, 21 Dec 2005, Rick Measham wrote:

my $DateTimeGPS = DateTime::Decorated( with => 'GPS' );


Dave Rolsky wrote:
This means you're sticking a Decorated() function into the DateTime 
namespace.  Is that intentional?  It seems awfully weird.


Oops! My bad ..
my $DateTimeGPS = new DateTime::Decorated( with => 'GPS' );



There are a couple disadvantages to this approach:

* Sticking everything in one namespace (DateTime) can lead to name 
collisions.


So maybe:
   package DateTime::Extended::GPS;
   @ISA = qw/DateTime/;

Rather than decorating, we add an 'Extended' namespace. However this 
doesn't allow mixins that give us more than one extension at a time.


* Looking at the code, it's not clear that some of the methods that 
appear to be in that namespace are not available there normally.  This 
makes it hard to look up docs, for example.


So .. we need to require decorations include a namespace in their methods:
   DateTime::Decorated::GPS::gps_*
but I hate that :)

I really wish we could come up with a cleaner way to get the same 
functionality.  Most importantly, I wouldn't want this to be the _only_ 
way to do this.  So if I want to construct a DateTime object from a year 
& week, I shouldn't have to create a new decorated class and do it that 
way.


Maybe split the whole thing up:

   %hash = DateTime::Util::GPS::gps2hash(
  week => 88, second => 22302
   );
   $dt = new DateTime( %hash );

That ::Util module can then be called by the ::Decorated module and also 
by the ::Extended module. That means there's just one main place to fix 
errors :)


The Decorated and Extended modules could even just auto-wrap the Util by 
looking for known entities:

   package DateTime::Util::GPS;
   sub constructor { DateTime->new( gps2hash( @_ ) ) }

   sub methods {(
  weeks => sub {
 (datetime2gps($_[0]))[0];
  }
  seconds => sub {
 (datetime2gps($_[0]))[1];
  }
   )}

Then Extended.pm looks for &constructor and &methods and make an 
DateTime::Extended::GPS namespace. Decorated looks for these methods and 
mixes them into DateTime with a gps_ prefix.


Maybe we even create a glue.pl that turns creates these links statically 
rather than dynamically... and would even create POD that tells the user 
to see the ::Util for the documentation.


Just thoughts.

Cheers!
Rick Measham

--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: Fwd: [PBP-pm] Working with dates

[Rick Measham]

- Forwarded message from Jay Buffington <[EMAIL PROTECTED]> -


Hi Everyone.

I'd like some feedback on best practices for working with dates in
perl.  Here's what I came up with:

--- >8 ---

Displaying Dates
Use CPAN's DateTime to format dates for display.


If you're going to be using DateTime, then stick with DateTime. It 
probably does everything you need*.


my $lower = new DateTime(year => 2005, month => 12, day => 12 );
my $upper = new DateTime(year => 2005, month => 12, day => 19 );
my $date  = DateTime->today();

if (($date >= $lower) && ($date <= $upper)) {
   print "Today is between Dec. 12th and Dec. 19th!\n";
}

Plus, each of those three DateTimes can be in a different time zone and 
the result will still return the truth.



You can return the same hash from a function (though I'd personally 
return a hash rather than a hashref) and feed it straight into 
DateTime's constructor:


my $date1 = DateTime->new( %{ yourFunction() } );
my $date2 = DateTime->new( myFunction() );

Cheers!
Rick Measham

* If it doesn't do everything you need, then let the datetime list know 
so we can consider it!


--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: Date range from Week number

[Rick Measham]

Dave Rolsky wrote:
This seems like something that'd be a nice add-on constructor for 
DateTime.pm.  Maybe we need some DateTime::Constructor::* modules or 
something, because I sure don't want dozens of constructors in the core 
code.


We *are* missing a namespace but I'm not sure that it's ::Constructor:: 
.. this problem seems similar to the GPS one. I started playing with 
that the other day, and couldn't work out where if fit:


1. ::Format:: These modules are for inputting datetimes in a string 
format and retrieving them in the same format. The GPS format is just a 
different way of representing dates (in weeks and seconds since a given 
epoch)

2. ::Calendar:: These are for non-Gregorian datetimes. GPS is gregorian.
3. ::Event:: A gps datetime isn't an event

So now I come back to DateTime::Decorated that I started back in June to 
deafening silence... Unless I get any objections I'll get it ready to 
go, and release GPS and WeekConstructor at the same time.


my $DateTimeGPS = DateTime::Decorated( with => 'GPS' );

my $dt = $DateTimeGPS->from_gps( week => 87, second => 23456 );

# Internally, this is a standard DateTime, but the decorator has
# given us a new constructor. Likewise, we now have extra accessors:

print $dt->gps_week;   # 87
print $dt->gps_second; # 23456

# and a couple of setters:

$dt->set_gps_week( 88 );
$dt->set_gps_second( 0 );

SIMILARLY:

my $DateTimeWeek = DateTime::Decorated( with => 'WeekConstructor' );

my $dt = $DateTimeWeek->from_week( year => 2005, week => 48 );

AND COMBINING TOO

my $DateTime2 = DateTime::Decorated(with => ['GPS', 'WeekConstructor']);

my $dt = $DateTime2->from_week( year => 2005, week => 48 );

print join('G', $dt->gps_week, $dt->gps_second);

__END__

Cheers!
Rick Measham


--
 "War is God's way of teaching Americans geography."
 -- Ambrose Bierce

Re: moving FAQ to the wiki?

[Rick Measham]

Dave Rolsky wrote:
I was thinking this might be a good idea.  The one thing we'd lose is 
the tests built into the FAQ for testing examples.  This is a really 
nice feature, but I think the benefits of moving to a wiki are bigger.


I agree with putting it on the wiki .. there's been times when I wanted 
to add to it, but (IIRC) that will mean checking out the cvs and 
submitting a patch.


It's a pity to lose the tests though ..

Cheers!
Rick Measham

Re: A sane answer for datetime subtraction?

[Rick Measham]

Dave Rolsky wrote:
I think this is about as good as I can get it without simply forcing 
lots of additional complexity onto the user by adding many options to 
the API, which I am loathe to do.


To sing my usual song: This looks great .. anyone who wants anything 
else should use something like DateTime::Decorator::UTCMath


I'm hoping, however, that Rick will make sure that users can use 
DT::F::Duration to handle anything that they cannot do with DateTime.pm 
itself ;)


I've decided that DateTime math is quite possibly the ugliest thing in 
the entire world -- especially after reading the Wiki :)


Thanks heaps for all this work, though I can see that my job comes next 
 and it will be a doozy.


Cheers!
Rick Measham

Re: Leap Seconds and Epochs

[Rick Measham]

mathieu longtin wrote:

Cause time since the epoch doesn't measure leap seconds. See in the
DateTime manual, under the epoch() method description.


I'm aware that it doesn't measure them ... but I'm wondering why? Surely 
that makes it Capital-W-Wrong. Perl will return the Wrong number of 
elapsed seconds since 1970  ...


Cheers!
Rick Measham

Leap Seconds and Epochs

[Rick Measham]

Why does time() return a multiple of 60? Surely each time there's a leap 
second time()%60 should increment?


Cheers!
Rick Measham

Re: DateTime::Format::Duration test failure

[Rick Measham]

Ask Bjørn Hansen wrote:
DateTime::Format::Duration is failing a few tests..  Test output  
below.  Perl -V below that.   DateTime etc should be the latest  versions.


Thanks Ask,

It's due to changes made in DateTime itself a little while back -- date 
math changed to using UTC rather than local for additions/subtractions.


I've CC'd this to the main list ...

Dave, what's the status on DateTime math? Should I fix DT:F:D to work 
with the current DateTime, or are you likely to find the tuits you need 
sometime soon?


Cheers!
Rick Measham

Re: Time zones?

[Rick Measham]

Jason Bodnar wrote:

I'm using DateTime and DateTime::Format::Strptime to convert some third-party
data into MySQL-compatible formats and changing the time zone to GMT. The data
had PDT as the time zone until this past weekend when Daylight Savings Time
ended and now has PST. DateTime complains that PST is ambiguous so I tried
replacing PST with 'US/Pacific', 'America/Los_Angeles' and 'PST8PDT' but
DateTime says it doesn't recognise [sic] any of those. So what timezone label
will DateTime accept for Pacific Standard Time?


In a string? None of them ... though I might patch it to accept the 
Olson America/Los_Angeles ...


At the moment, if you know the zone of your times, you can add it to the 
constructor:


my $parser = DateTime::Format::Strptime->new(
pattern   => $your_pattern,
time_zone => 'America/Los_Angeles'
);

Though I expect to get a new version out today with another bug-fix 
(also TZ related)


Cheers!
Rick Measham