Re: Missing *pm files for DateTime::Locale

[Dave Rolsky]

Hi Norbert,

The way the locale data is packaged changed a while back in the 1.00
release in 2015. There's no longer a `.pm` file per locale. If you want to
preload locale data, you should just call `DateTime::Locale->load($locale)`.

I'm guessing you have some `Storable`-serialized `DateTime` objects that
included pre-1.00 locales. The only way to thaw them is probably to install
an older `DateTime-Locale` release.

Longer-term, I'd suggest _not_ using `Storable` to serialize data. It
generates data that is too tied together with the internals of the
libraries that produced the objects.


Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch


On Fri, Nov 17, 2023 at 12:34 PM Zacharias, Norbert via datetime <
datetime@perl.org> wrote:

> Hi all,
>
> I try to install DateTime. Even there is no error reported during
> installation it seems that the *pm files like en_US.pm are missing. The
> only related files I can find are *.pod like en_US.pod.
> If I try to use Storable::retrieve I get an error message
>
> perl -e "use Storable retrieve ; \$x=retrieve('./VeriPars.dat');"
> Can't locate DateTime/Locale/en_US.pm in @INC (you may need to install the
> DateTime::Locale::en_US module) (@INC contains:
> /usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads
> /usr/local/share/perl5/site_perl/5.32
> /usr/lib/perl5/vendor_perl/5.32/x86_64-cygwin-threads
> /usr/share/perl5/vendor_perl/5.32 /usr/lib/perl5/5.32/x86_64-cygwin-threads
> /usr/share/perl5/5.32) at
> /usr/lib/perl5/5.32/x86_64-cygwin-threads/Storable.pm line 421.
> BEGIN failed--compilation aborted, at -e line 1.
>
> Storable is uptodate:
>
> Storable
> -
> (no description)
> N/NW/NWCLARK/Storable-3.25.tar.gz
>
> /usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads/Storable.pm
> Installed: 3.25
> CPAN:  3.25  up to date
> Nicholas Clark (NWCLARK)
> nwc10+please+use+perlbug+for+perl+quer...@colon.colondot.net
>
>
> Do I miss something?
>
> Thanks in advance for your help
>
> Norbert Zacharias
>
> UL International GmbH
> Kasinoplatz 3
> 26122 Oldenburg, Germany
>
> T:: +49 441 77937 110 | F:: +49 441 77937 133 | norbert.zachar...@ul.com|
> www.ul.com
>
> Commercial Register No.: Amtsgericht Oldenburg, HRB 130241
> VAT DE117895432 St-Nr. 20/200/32924-PAN AADCD15130A
> Geschäftsführer/Managing Director: Mirko Bautz, Ryan David Robinson, Gitte
> Schjøtz
>
>
>
> This e-mail may contain privileged or confidential information. If you are
> not the intended recipient: (1) you may not disclose, use, distribute, copy
> or rely upon this message or attachment(s); and (2) please notify the
> sender by reply e-mail, and then delete this message and its attachment(s).
> Underwriters Laboratories Inc. and its affiliates disclaim all liability
> for any errors, omissions, corruption or virus in this message or any
> attachments.
>

Re: DateTime::Format::MySQL format_time incorrect

[Dave Rolsky]

Hi Marcel,

Yes, that sounds like a bug. I've cc'd the current maintainer of that
module, Mike Wisener, but I'd also suggest reporting the bug via rt.cpan.org
at https://rt.cpan.org/Public/Dist/Display.html?Name=DateTime-Format-MySQL


Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch


On Wed, Jul 5, 2023 at 3:03 PM Marcel Versteeg via datetime <
datetime@perl.org> wrote:

> The DateTime::Format::MySQL formats microseconds incorrectly in the method
> format_time. It simply concatenates the number of microseconds after the
> formatted hms, however this is incorrect when the number of microseconds is
> less than 100,000.
>
> If a date object returns 12,345 microseconds at 5 am, the function
> format_time returns 05:00:00.12345, but it should return 05:00:00.012345
> (mind the '0' between the period and the 1).
>
> Another example would be if the number of microseconds is 1 at 6 am, where
> format time returns 06:00:00.1, but instead it should return 06:00:00.01
>
> Sincerely,
> Marcel Versteeg
>
>
>

Re: Surprising results from predefined CLDR formats

[Dave Rolsky]

The formats returned by "$locale->available_formats" are keys that you use
to access the localized format from "$locale->format_for($key)".

So what you wanted to write was this:

```
use DateTime;

my $dt = DateTime->now( locale => 'en-US' );

for my $fmt ( $dt->locale->available_formats ) {
my $val = $dt->format_cldr( $dt->locale->format_for($fmt) );
say "$fmt : $val";
}
```

Each locale will implement some subset of the possible keys, but the keys
themselves are the same between locales. In other words, for all locales
that have a format for "abbreviated month with numeric day", the key will
be "MMMd", but the actual formats returned by `$local->format_for('MMMd')`
will differ.


Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch


On Tue, Feb 23, 2021 at 11:27 PM BPJ  wrote:

> Please consider this code:
>
> ``perl
> use DateTime;
>
> my $dt = DateTime->now( locale => 'sv' );
>
> for my $fmt ( $dt->locale->available_formats ) {
>   my $val = $dt->format_cldr($fmt);
>   say "$fmt : $val";
> }
> ``
>
> Most of the formatted strings seem to be missing some whitespace and have
> things in a surprisising order.
> E.g. `MMMd` gives `feb.23` where I would have expected `23 feb.`.
>
> I don't know if/what I'm doing wrong, or whether this is a DateTime,
> DateTime::Locale or CLDR bug or indeed if it is a bug at all.
>
>
> --
> Better --help|less than helpless
>

Re: Upgrading DateTime::Format::Roman

[Dave Rolsky]

Unfortunately with co-maint I can't give anyone else permissions. You
should contact modu...@perl.org and ask them to help. See section 4.2 of
https://pause.perl.org/pause/query?ACTION=pause_operating_model for details.


Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch


On Wed, Nov 28, 2018 at 12:03 AM Jean Forget  wrote:

> Now I talk to Dave R.
>
> Dave, I have just seen that you have co-maintainer status
> on DateTime::Format::Roman. So can you upgrade the module
> according to my GitHub repo:
> https://github.com/jforget/DateTime-Format-Roman
> or can you give me co-maintainer status please?
>
> Thank you in advance,
>
> Jean Forget
> JFORGET at CPAN dot org
>
> Le 26/11/2018 à 07:32, Jean a écrit :
> > You wrote the module DateTime::Format::Roman in 2003 and 2004.
> > At this time, it was up to date and conform to the CPAN and Perl
> > rules. But since then, the world has moved, and so did Perl and
> > CPAN and the CPAN testers. And now, with recent versions of Perl,
> > DT::F::R does not even compile.
> >
> > In July 2011 I created a RT ticket with a patch.
> > https://rt.cpan.org/Ticket/Display.html?id=69845
> > But you have not answered to me and you have not patched
> > your module. Your module is mentioned in Neil Bower's list of
> > CPAN Adoption Candidates:
> > http://neilb.org/adoption/
> >
> > If you are no longer interested in DateTime,
> > please can you give me co-maintainer status, or even
> > full ownership?
> >
> > I have forked this module from Gitpan, I
> > have applied my patch and I have made other improvements.
> > So the module is ready on Github. See:
> > https://github.com/jforget/DateTime-Format-Roman
> >
> > And by the way, excuse me for the typos to your name
> > that you could find in this Git repository.
> >
> > Thank you in advance for giving me a maintenance
> > bit on DateTime::Format::Roman.
> >
> > Jean Forget
> > JFORGET at CPAN dot org
> >
>
>

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

[Dave Rolsky]

On Tue, Jul 11, 2017 at 10:56 AM, Paul Hoffman  wrote:

> On Mon, Jul 10, 2017 at 09:44:15PM +0100, Zefram wrote:
> > Thomas (HFM) Wyant wrote:
> > >One of the edge cases with eval {} is the possibility that $@ gets
> > >clobbered before you get your hands on it.
> >
> > The possibility of it being clobbered by a destructor was fixed in 5.14.
> > (Destructors that do this are considered buggy, for pre-5.14 perls,
> > and are individually easy to fix, so the problem is still manageable on
> > those perl versions.)
>
> And in perl < 5.14 you can work around it easily enough:
>
> my $ok;
> eval {
> ...
> $ok = 1;
> };
> if ($ok) {
> ...
> }
>

I'd write that as ...

my $ok = eval { ...; 1 };
if ($ok) { ... }

I think that reads a little better.

Of course, I'd also just use Try::Tiny and use a catch instead of checking
$ok in the first place.

Re: How to tell (in advance) if a date-time is ambiguous?

[Dave Rolsky]

While you could in theory write code that would be correct for all past
datetimes, the future doesn't work the same way. As Eric noted, time zones
are political. I have seen DST transitions altered with mere days (or
less!) notice given. This means that anything you determine about the
future could be wrong.

If you're trying to avoid these, the best advice I could give would be to
avoid the 12am-4am window, which AFAIK is when most (all?) transitions have
occurred historically.


Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch

On Mon, Jul 10, 2017 at 1:02 PM, Binarus <li...@binarus.de> wrote:

> Dear experts,
>
> a few days ago I have got great help from this list, so I hope I may ask
> another (probably stupid) question (I am now having the opposite problem
> than back then):
>
> Using DateTime, is it possible to tell in advance if a certain date-time
> which is given in a certain locale will be ambiguous due to switching
> from DST to standard time?
>
> Example (taken from DateTime's documentation):
>
>   my $dt = DateTime->new(
>   year  => 2003,
>   month => 10,
>   day   => 26,
>   hour  => 1,
>   minute=> 30,
>   second=> 0,
>   time_zone => 'America/Chicago',
>   );
>
> Now $dt is ambiguous: The clock has been turned back to 01:00:00 h at
> 02:00:00 that night, so the time 01:30:00 h has occurred twice.
>
> Even after thinking many hours about it, I haven't found a reasonable
> general method to determine if an arbitrary date-time is ambiguous in
> the sense above.
>
> Possibly, I could subtract different time spans from the date-time in
> question and check if the result is the expected one and use that to
> find out if it is ambiguous, but this would cost much CPU time.
>
> So I would like to ask if somebody knows a general, reasonable method
> for solving that problem, given the following conditions:
>
> 1) We don't know the time span the clock is turned back when switching
> from DST to standard time. It might be one hour in most time zones /
> countries, but after all, some weird person could decide that it is 18
> minutes and 13 seconds or 5 hours, 53 minutes and 42 seconds.
>
> 2) We don't know whether the point in time when the switch occurs is
> exactly at an hour's end / begin. Again, some weird person could decide
> that the switch happens at 08:48:27 am.
>
> I know that there are not many persons on the world that are *that*
> weird, but on the other hand, I don't want to implement an algorithm
> which uses assumptions which are not safe.
>
> As a last resort, there is at least one other module (AFAIK) which I
> could use to extract the daylight saving switching times and time spans
> from the time zone database, and I could use that information to solve
> my problem. But this would probably mean to reinvent the wheel, so I'd
> like to avoid it.
>
> Thank you very much in advance,
>
> Binarus
>

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

[Dave Rolsky]

On Wed, Jul 5, 2017 at 12:49 PM, Eric Brine <ikeg...@adaelis.com> wrote:

> On Wed, Jul 5, 2017 at 12:43 PM, Dave Rolsky <auta...@urth.org> wrote:
>
>> On Wed, Jul 5, 2017 at 11:27 AM, Bill Moseley <mose...@hank.org> wrote:
>>
>>> Haven't those issues with eval been addressed in more recent versions of
>>> Perl?  Well, that's one issue, but there are others, for example $@ being
>>> set to a false value.
>>>
>>
> That's kinda hard to do by accident.
>
>

Assuming you are in full control of all the relevant code, yes, I suppose
it is. That said, a little extra defensive programming usually seems like
the best choice to me. What is gained by discouraging people from using
CPAN modules that help avoid corner cases?


Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch

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

[Dave Rolsky]

On Wed, Jul 5, 2017 at 10:23 AM, Eric Brine <ikeg...@adaelis.com> wrote:

> On Wed, Jul 5, 2017 at 10:59 AM, Thomas (HFM) Wyant <
> harryfm...@comcast.net> wrote:
>
>> One of the edge cases with eval {} is ...
>>
>
> All the edge cases are covered by the previously linked:
> https://metacpan.org/pod/Try::Tiny#BACKGROUND
>

Yes, this is exactly why I would recommend always using Try::Tiny over
plain eval.

Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch

Re: small DateTime optimization

[Dave Rolsky]

On Wed, 15 Mar 2017, Flavio S. Glock wrote:


We've been using this patch at work for years, and I just forgot to contribute 
it back. I hope you find it worth applying.

I believe the typical use case was:

  my $dt = $param || DateTime->now();

In this case $param is used in boolean context, which makes a fallback call to 
_stringify(). With the patch, "boolean" just returns true.


I committed this to master. In the future please feel free to just make a 
GitHub PR.



Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch

Re: FW: timelocal() discrepancy vs DateTime->epoch

[Dave Rolsky]

On Tue, 14 Mar 2017, Lu Feng wrote:


I noticed that the UNIX time from timelocal() started to differ from that you 
get from using DateTime module, for dates earlier than 11/6/1910.
 
For the America/New_York local timezone, timelocal() thinks there was a DST 
switch on 11/6/1910, while DateTime module thinks there was none.


I'm pretty sure timelocal() is wrong here, though I'm not sure why. There 
was no DST transition in that zone in 1910. In fact, there wasn't really a 
time zone until 1918. The pre-1918 zone file in the Olson database is just 
using local solar time, but it's not very meaningful. If you really care 
about local times in the early 1900s you probably need to calculate the 
solar noon for the given lat/long.



Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch

Re: Statut of DateTime::TimeZone::LMT

[Dave Rolsky]

On Thu, 2 Feb 2017, Jean Forget wrote:


I need a commit bit to DT::TZ::LMT. I received it from Rick M and
I released a new version of this module the next day. So this question
is closed.


Looks good.

You probably want to "unfork" your repo from the gitpan repo so that yours 
looks like the "parent" repo when people view it on GitHub. You can 
contact GitHub staff to do this for you.



Or nearly closed. I have received a git pull request from
Karen Etheridge for a few improvements on Makefile.PL. I was waiting
for bigger mistakes to fix and release a new version to CPAN. And
actually, I forgot about Karen's improvements. Now, maybe I will
release a new version with just Karen's improvements. See:
https://github.com/jforget/DateTime-TimeZone-LMT/pull/1


You might want to investigate Dist::Zilla, since it will make sure all of 
this stuff is done properly for you.



Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch

Re: Statut of DateTime::TimeZone::LMT

[Dave Rolsky]

On Wed, 17 Feb 2016, Jean Forget wrote:


As a comparison, with DateTime::Locale, there is a register()
function to hide the internals. Is it possible to have a similar
function in a future version of DateTime::TimeZone
so we will be immune to changes of the internals?


Sorry I never responded to this. I think I just forgot.

So yes, I could imagine something similar. That said, the Locale 
registration system is kind of a pain to maintain and I had to bend over a 
bit backwards when I reworked how the internals of the Locale code worked.


Meanwhile, I have updated DateTime::TimeZone::LMT to use the proper 
version of the internals, depending on the version of 
DateTime::TimeZone. I can release a working version as soon as I get a 
commit bit and a round tuit.


To what do you need a commit bit?


Cheers,

Dave Rolsky
http://blog.urth.org
https://github.com/autarch

Re: Storable and DateTime::Format::Strptime

[Dave Rolsky]

On Sat, 22 Oct 2016, Bill Moseley wrote:


Should or can the formatter have a Storable hook to remove the parser?   Any 
suggestions on an easy workaround?


It'd probably be relatively easy to add Storable hooks to the module. All 
it needs to do is save the arguments passed to new() and then freeze 
those instead of the object itself.


Patches would be welcome.


Cheers,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Timezone volunteer task list?

[Dave Rolsky]

On Wed, 12 Oct 2016, Jay Hannah wrote:


I volunteered in response to

  http://blog.urth.org/2016/10/05/datetime-core-team-members-wanted/

I'm most interested in helping with DateTime::Timezone. It appears Issues 
aren't activated in the github repo, and I'm not seeing outstanding issues in 
rt.perl.org. Is there a TODO list somewhere?

Is there a Slack?


Yes, I made a Slack channel. I already sent you an invite, but maybe to 
the wrong email. I'll invite this one.


Also, if anyone else on the list would like to join, please let me know 
privately.



Cheers,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime and Etc timezones

[Dave Rolsky]

On Sun, 26 Jun 2016, Steve James 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?


There is support in the code that parses the IANA db files to generate 
these zones, but they're not included by default.


Note that these zones are _very_ confusing, and I strongly recommend 
against using them. The IANA definition of "Etc/GMT+6" is a zone 6 hours 
_behind_ UTC. This is a historical POSIX thing. Only very very technical 
(and probably old) users would ever expect this.


As Rick pointed out, you should encourage people to use zones named for a 
city anyway, since that way you get the appropriate DST transitions 
included.



Cheers,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

New version of DateTime::Locale coming soonish

[Dave Rolsky]

http://blog.urth.org/2015/09/27/please-test-datetimelocale-0-93/

Short summary - I'm working on a new version which will get us up to date 
with CLDR, but there's some backwards incompatibilities, so please test 
your code.


For those curious about the impact on CPAN, please see 
https://rt.cpan.org/Ticket/Display.html?id=107536


Short summary - I've already provided patches/releases for some modules 
that the new version breaks. I'm not planning on providing more fixes but 
I'm open to being convinced that one of the modules I'm not fixing is 
important.



Cheers,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Must DateTime load all Locales?

[Dave Rolsky]

On Sat, 9 Aug 2014, David E. Wheeler wrote:


What could speed things up would be to pre-generate the data structures that are 
built by calling -register on everything in the Catalog module.


It builds up in-memory data structures for all of the locales? Wow. Yeah, seems 
like those could be encapsulated in the locales themselves or something, no?


Or rather than building this all up via repeated calls to _register, the 
Catalog code could just contain the fully realized structure.



That all said, DT::Locale is woefully crufty and out of date. I haven't kept up 
to date with the CLDR data for years because the approach that DT::Locale uses 
to generate individual locales makes it incredibly hard to deal with data 
format changes in CLDR.


Ah. So some locale results will probably be wrong now, eh?


Oh yes.


Nick Patch had mentioned that he was interested in working on proper CLDR 
support for Perl (which is more than just DateTime info), and I was hoping he'd 
take all this over ;)


Is CLDR::Number part of that, perhaps?

 http://search.cpan.org/dist/CLDR-Number/


Probably. But CLDR is a huge beast. I really think we need a Perl 
interface to libicu, although there'd be a serious mismatch between how it 
handles dates (POSIX style with no leap seconds) and DateTime. So just 
having the interface would just be a first step.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Must DateTime load all Locales?

[Dave Rolsky]

On Mon, 11 Aug 2014, David E. Wheeler wrote:


On Aug 11, 2014, at 10:01 AM, Dave Rolsky auta...@urth.org wrote:


It builds up in-memory data structures for all of the locales? Wow. Yeah, seems 
like those could be encapsulated in the locales themselves or something, no?


Or rather than building this all up via repeated calls to _register, the 
Catalog code could just contain the fully realized structure.


How hard would that be to do?


Hard and not hard ;)

The Catalog is currently generated as part of the code that generates each 
individual locale. Changing that part of the code generator isn't too 
hard. The trick is you have to use the exact version of the CLDR data that 
this generator can parse, which is CLDR 1.7.1. You can probably get it 
from their historical archives or repo.



-ave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Must DateTime load all Locales?

[Dave Rolsky]

On Tue, 5 Aug 2014, David E. Wheeler wrote:


On Aug 5, 2014, at 4:18 PM, Olivier Mengué olivier.men...@gmail.com wrote:


Here is below the output (latest releases of DateTime, DateTime::Locale, 
DateTime::TimeZone on perl 5.20.0).
DateTime::Locale::Catalog is the module that contains all the locales names.
David, is it that module that you worry about or have you found something worse?


I think the overhead comes in the DateTime::Locale::_register() function, which 
is called once for each locale returned by DateTime::Locale::Catalog. I would 
not think any locales would be loaded until they were needed.


And you would be correct. The individual locale classes are not loaded 
until you call DateTime::Locale-load


What could speed things up would be to pre-generate the data structures 
that are built by calling -register on everything in the Catalog module.


That all said, DT::Locale is woefully crufty and out of date. I haven't 
kept up to date with the CLDR data for years because the approach that 
DT::Locale uses to generate individual locales makes it incredibly hard to 
deal with data format changes in CLDR.


Nick Patch had mentioned that he was interested in working on proper CLDR 
support for Perl (which is more than just DateTime info), and I was hoping 
he'd take all this over ;)



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Moving forward on the new DT::TZ

[Dave Rolsky]

Zefram, I tried to email you privately but your system rejected my email 
as spam. Hopefully this'll go through.


I'd love to get the new DT::TZ finally released. If you don't have the 
tuits to work on this could you share a repo with me? If you do have the 
tuits could you share the repo anyway?



Thanks,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: localized date formats

[Dave Rolsky]

On Sun, 26 Jan 2014, Bill Moseley wrote:


I lost track of this and it came up again this morning.   I'm not having a lot 
of luck researching what should be done.
I see in 
http://cldr.unicode.org/cldr-features#TOC-Locale-specific-patterns-for-formatting-and-parsing
 there's a heading Translation of Names
where there's a list item timezones, timezone cities but no link.

But, perhaps a more on point and useful question is:

I need to always show times with a timezone, and in a way that is localized for 
the user.    What is the best way to do that currently with
DateTime?


Should EST be translated?   What about UTC? (e.g. if using UTC + offset)   
I suspect UTC + offset isn't a very friendly timezone for many
people.


Locale ar-sa shows the following.  Is America/New_York and EST not translated 
on purpose?

using format: full    : الأحد، 26 يناير، 2014 America/New_York 10:37:42 ص
using format: long    : 26 يناير، 2014 EST 10:37:42 ص
using format: medium  : 26‏/01‏/2014 10:37:42 ص
using format: short   : 26‏/1‏/2014 10:37 ص


I never got around to doing the time zone localization work. At this 
point, DateTime::Locale is _years_ out of date with regards to CLDR. The 
approach I was using to parse CLDR and generate locales was not very 
robust, so when the CLDR files changed it was a huge amount of work to 
release a new DateTime::Locale.


All this is to say that we could really use an updated DateTime::Locale ;)

There are a few ways to do this:

1. Essentially what I'm doing now - which can be good enough, but is 
hard to get 100% correct because of things like fallback locales, locale 
inheritance, etc.


2. Implement an ICU library in Perl that handles the full lookup reslution 
logic required by CLDR. Said logic was not actually documented anywhere 
last I looked, of course. So that means poking around in the Java and/or C 
libraries to figure out what it should do.


3. Implement Perl bindings to libicu. I like this idea except I wonder if 
this makes Windows support much harder. On the plus side, it'd almost 
certainly be faster than #2 and much more correct than #1.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Invalid version format

[Dave Rolsky]

On Mon, 6 Jan 2014, Bill Moseley wrote:


I have this code running in a Catalyst app running under mod_perl:


I'm inclined to blame mod_perl, since in my experience it tends to do 
weird things when loading modules, depending on how you load them 
(PerlRequire vs in module loaded via a handler, etc.).


The bit in your other message about attempt to reload ... aborted makes 
me wonder if you are for some reason using Apache(2)::Reload or something 
similar in production. If you are, you really shouldn't.


You may just want to punt and run the app via starman or something like 
that, too. I find this to be much simpler when using Catalyst. There's 
less magic.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::TimeZone and etcetera zones

[Dave Rolsky]

On Thu, 5 Dec 2013, Alfie John wrote:


On Thu, Dec 5, 2013, at 09:40 AM, Zefram wrote:

Alfie John wrote:

I guess it's a tautology seeing as that's what's defined in the etcetera
file, but was I wrong in assuming that UTC+11 meant Etc/GMT+11?


Yes.  Etc/GMT+11 is UT-11h, and Etc/GMT-11 is UT+11h.  You can also see
this by looking in the Olson etcetera file:

# Zone  NAMEGMTOFF  RULES   FORMAT  [UNTIL]
ZoneEtc/GMT-11  11  -   GMT-11
ZoneEtc/GMT+11  -11 -   GMT+11

Such zic input, specifically the GMTOFF column, uses the usual sign
convention; you can see here that the zone names use the opposite
convention.


Cool, thanks for the clarification.

I'd hate to think of how much software out there assumes the same as I
did.


Does any sane software actually use these ancient time zone names?

The only useful thing to do is use a zone like America/Chicago so you get 
DST transitions and such. If you want a DST-less zone that's simple to 
understand, you should use UTC, not some fixed offset from UTC (which will 
very confusingsly match up with different local time zones as DST comes 
and goes in various places).



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: 1) Datetime website 2) recommended practice to alter API

[Dave Rolsky]

On Fri, 27 Sep 2013, Jean Forget wrote:


When I try to access the http://datetime.perl.org/wiki/datetime/
website, I get:
--- begin of copy-paste
Service Temporarily Unavailable
The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.
--- end of copy-paste
Can you check the web server, please?


My server crashed hard on Monday. I've moved to Linode but I haven't quite 
gotten everything running again.



Another question is: which is the earliest Perl version
should we target? Dave wanted to target 5.005 or maybe 5.004,
but that was more or less 10 years ago, when the 5.8 version
was reigning supreme. But now, we have reached 5.18 and
5.14 is no longer officially supported.


I'd say 5.8 or 5.10. Unfortunately, while p5p may only support 5.16+, 
there are still distributions in wide use like RHEL that use old Perls.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

DateTime wiki is back

[Dave Rolsky]

The wiki should be back (http://datetime.perl.org). Please let me know if 
you find any breakage (besides user images, which I know are broken)



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DT:TZ 1.902

[Dave Rolsky]

On Sat, 21 Sep 2013, Zefram wrote:


Another new version of my DT:TZ rewrite.  CPAN-style tarball at

http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.902.tar.gz

Public git repo at

git://lake.fysh.org/zefram/DateTime-TimeZone.git

The zic issues affecting a couple of zones have now been resolved.
My zic patches were accepted upstream, and there's also a new version
of the tzfile format which tackles tricky rules a different way.
DT:TZ:Tzfile now handles the new tzfiles.

Time::OlsonTZ::Data now has the hooks that the Debian folks want in
order to roll their own version as part of their tzdata package.

I think we're now (at last) on the point of being able to replace DT:TZ
on CPAN.


So I tried installing the above tarball and it breaks a DateTime test 
- t/34set-tz.t


It's just an error message change but it's an error message that other 
people might be looking for in their code too, since it's the kind of 
thing you might have to code around. I think it'd be good to keep this 
backwards compatible.


The message is from an attempt to set a DateTime to an invalid time. 
Currently it's something like Invalid local time for date in time zone 
...


The new one is local time 2013-03-10T02:04:00 does not exist in the 
America/Los_Angeles timezone due to offset change


Arguable the new message is better, but I don't think this is so important 
that it's worth break back compat for.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Shutting down the Sourceforge project for the DateTime suite

[Dave Rolsky]

On Sun, 16 Dec 2012, Dave Rolsky wrote:

There's an old SF project that has an SVN repo with many, many DateTime 
modules - http://sourceforge.net/projects/perl-date-time


AFAICT, no one is using the the SVN repo any more. The last holdout seemed to 
be Flavio Glock, and he just moved his projects to github.


Unless someone objects, I'm going to delete this project at some point in the 
next few weeks. I'll make sure to grab an archive of the SVN repo before I do 
that, though.


So when I said next few weeks I really ment next year. The project has 
been deleted.


I mirrored the old SVN repo in case anyone wants anything from it. If
someone pesters me I can convert it to an ugly git repo, but AFAIK all the 
individual modules in there are already maintained (or not) elsewhere.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime setting invalid zone.

[Dave Rolsky]

On Tue, 12 Mar 2013, Bill Moseley wrote:


So, I found some old that wrapped a set_time_zone in an eval.

my $dt = DateTime-new(
   year = 2013,
   month = 3,
   day = 10,
   hour = 2,
   minute = 4,
   time_zone = 'floating',
);

eval { $dt-set_time_zone( 'America/Los_Angeles' ); };

print $dt  . $dt-time_zone . \n;


The code was using the eval to check if the timezone set failed, and if it
did went on to do something else with $dt (like set to UTC).   But, it
seems like even if it fails the time zone gets set.  The above returns this
invalid time:

2013-03-10T02:04:00
DateTime::TimeZone::America::Los_Angeles=HASH(0x7fc4c2aafc90)

My question is should DateTime associate that timezone to $dt if the
set_time_zone call actually throws an exception?


This is almost certainly a bug.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime locale names and wide characters

[Dave Rolsky]

On Fri, 18 Jan 2013, Shane McCarron wrote:


The @data list is then sorted (by desc) and used to populate a select
element in a web form.  Here's the weird thing.  When I am using this under
Apache on a Linux platform in a CGI application, I get a warning that I am
printing 'wide characters' when I use data from the 'desc' as the content
of an 'option' element.  What I *think* is that the data coming out of
DateTime::Locale is not properly encoded as Perl's utf8 internal encoding.
If I take the outout of the name() and native_name() methods and encode
them using Encode, then it no longer complains.  Is this expected
behavior?


I think you have the cause a bit backwards.

That warning means that you're printing data marked as UTF-8 to an output 
that expects to receive binary data. By default, all handles expect 
binary.


Calling Encode::encode() turns Perl's UTF-8 flag _off_. I've always found 
this use of encode (and decode) confusing, since I'd expect encoding to 
produce UTF-8, which it does, but it produces _bytes_.


The solution you're using is probably not the best idea. It's better to 
mark your output filehandle as UTF-8 with binmode() or by passing a layer 
to open:


  open my $fh, ':encoding(UTF-8)', ...;

In a webapp, you're probably printing to STDOUT so you can use binmode:

  binmode STDOUT, ':encoding(UTF-8)';

I'm not sure how this will interact with mod_perl's tying of STDOUT, 
though.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Shutting down the Sourceforge project for the DateTime suite

[Dave Rolsky]

There's an old SF project that has an SVN repo with many, many DateTime 
modules - http://sourceforge.net/projects/perl-date-time


AFAICT, no one is using the the SVN repo any more. The last holdout seemed 
to be Flavio Glock, and he just moved his projects to github.


Unless someone objects, I'm going to delete this project at some point in 
the next few weeks. I'll make sure to grab an archive of the SVN repo 
before I do that, though.



Dave Rolsky
Compassionate Action for Animals - http://www.exploreveg.org/
VegGuide.Org - http://www.vegguide.org/

Re: The default datetime format for the object’s locale

[Dave Rolsky]

On Thu, 25 Oct 2012, N Heinrichs wrote:


If the locale's definitions for the 'medium' formats are
wrong/outdated (see http://cldr.unicode.org/index/downloads) you could
propose an update to the locale class itself, but I am unsure of the
official way to do this.


Note that DateTime::Locale is quite behind the CLDR data these days. 
Fixing this is kind of a pain in the ass, since the LDML data keeps 
changing (sometimes changing internal structure) and the DateTime::Locale 
code does a completely half-assed job of parsing the LDML documents.


What I really want to do is write a proper Perl interface to libicu _or_ 
reimplement libicu in Perl, but that's a fairly big project.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

[rt.cpan.org #79845] [PATCH] sub-second precision and rounding

[Dave Rolsky via RT]

URL: https://rt.cpan.org/Ticket/Display.html?id=79845 

On Tue Sep 25 07:27:53 2012, MHASCH wrote:

 To demonstrate that the current rounding behaviour is not
 quite thought through, try:
 
   use DateTime 0.76;
   my $d = DateTime-new(
 year   =  2012,
 month  = 9,
 day=25,
 hour   =12,
 minute =39,
 second =59,
 nanosecond = 999876000,
 time_zone  = 'Europe/Berlin',
   );
   print $d-strftime('%H:%M:%S.%3N'), \n;
 
 This will print 12:39:59.1000 rather than 12:39:59.999.
 And no, please don't make it print 12:40:00.000 either.
 Rounding is just not the right thing to do by default.

There were a few RT tickets about this and I've thought about it a fair 
bit. I think your solution is right.

This gets really messy with a datetime like 2011-12-31T23:59:59.999

To round properly we'd have to round every single unit, including the 
year! There's really no way to do this in strftime and format_cldr 
anyway, since you can only dictate the formatting _per unit_, so you 
might not even be printing out all the units which need rounding.

Re: Windows Locales

[Dave Rolsky]

On Mon, 27 Aug 2012, David E. Wheeler wrote:


The code in question that sets the locale is:

   $dt-set( locale = POSIX::setlocale( POSIX::LC_TIME() ) );


I'm not sure why you think this would work on Linux either. On my system 
here's what I get:


  perl  -MPOSIX -E 'say POSIX::setlocale(POSIX::LC_TIME())'
  en_US.UTF-8

That locale will not make DateTime::Locale happy either.

Of course, this one's relatively easy to make into something DateTime can 
handle, whereas the Windows one is _way_ off. Either way, I think you may 
need to rethink how you translate the user's locale for DateTime.


I'm not really sure what the best way to do it is besides presenting users 
with an explicit choice.


With Windows, someone might want to maintain a master translation list of 
Windows names to CLDR names, much like we currently translate timezone 
names.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Windows Locales

[Dave Rolsky]

On Mon, 27 Aug 2012, David E. Wheeler wrote:


That locale will not make DateTime::Locale happy either.


Seems okay with it:


perl -MDateTime -MPOSIX -E 'my $dt = DateTime-now; $dt-set(locale = 
POSIX::setlocale( POSIX::LC_TIME() ) ); say $dt-locale'

DateTime::Locale::en_US=HASH(0x7fc90a297dd8)


Heh, go figure. I think I wrote that code, but forgot about it. It strips 
off any trailing character set in the locale code.


With Windows, someone might want to maintain a master translation list 
of Windows names to CLDR names, much like we currently translate 
timezone names.


I found Win32::Locale, which seems to do what I need it to.


Ah, cool. Looking at it I suspect it's probably out of date and missing 
some codes that might be used in Windows since 2004, but it's better than 
nothing.


I should add a mention of this to the DateTime::Locale docs.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Fiscal::Retail454

[Dave Rolsky]

On Thu, 5 Jul 2012, Jim Bacon wrote:

I would like the advice of the DT community at large as to what would be 
a good name for such a module and what namespace it should go in. On the 
surface one would say DT::Calendar, but the module would create dates 
for various events such as the start and end dates for fiscal periods 
and reporting dates as well as being able to answer questions such as 
What fiscal period does a given holiday occur in? This would suggest 
that DT::Event might be better. That said, because of the planned 
ability to change from one period to another by means of methods such as 
next and previous neither Event or Calendar might be appropriate 
as they seem to imply a static condition and this would be decidedly 
dynamic. This argues for keeping the new module in the Fiscal 
namespace with an appropriate name.


If the module is about giving a DateTime object for an event, like the 
next year in this wack calendar system, then it's a DateTime::Event 
module.


If it provides an alternate system for defining dates (Whooping Day 47 of 
Frobnitz Month) then it's a DateTime::Calendar.


If doesn't fit into either API comfortably, just call it DateTimeX::Foo 
and come up with an API that you think best expresses the problems you're 
trying to solve.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: epoch to UTCstring conversion at leap-second boundary

[Dave Rolsky]

On Fri, 6 Apr 2012, Andrew Davis wrote:


Looking at the error output, it seems clear that the DateTime module,
or the Format::Epoch piece, is internally attempting to create a DateTime
object using hour=24, minute=0, and second=0. That's an error for sure.


This is almost certainly a bug in DT::F::Epoch. I'd suggest filing this in 
rt.cpan.org.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: epoch to UTCstring conversion at leap-second boundary

[Dave Rolsky]

On Thu, 5 Apr 2012, Karen Etheridge wrote:


On Thu, Apr 05, 2012 at 01:32:24PM -0700, Andrew Davis wrote:

The 'hour' parameter (24) to DateTime::new did not pass the 'an
integer between 0 and 23' callback

I'm hoping someone can tell me the best way to avoid the error, and
get the 2008-12-31T23:59:60 output that I want.


This sounds like a bug in DateTime core - just as it isn't always invalid
for months (for February, in leap years) to be [0,28], it is not always
invalid for 'seconds' to be [0,59] or hours [0,23] (for leap seconds).


Say what? The hour is always 0-23, regardless of leap seconds or DST.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: packaging Time::OlsonTZ::Data

[Dave Rolsky]

On Tue, 20 Mar 2012, Zefram wrote:


Dave Rolsky wrote:

It's not like maintaining DT::TZ and updating it when there are new
Olson releases is a big hassle, so I don't mind doing it for a while.


Yes, that's another issue I was planning to raise.  Continued DT:TZ 1.xx
releases would give distros the choice of a lengthy period in which to
switch.  There are enough 1.xx version numbers left for another couple
of years.


I wasn't planning to continue 1.xx releases after 2.00 is out. I don't 
think there's much point to doing that.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: packaging Time::OlsonTZ::Data

[Dave Rolsky]

yOn Mon, 19 Mar 2012, Iain Arnell wrote:


On Mon, Mar 19, 2012 at 2:15 PM, Zefram zef...@fysh.org wrote:

Hi, I'd like to establish what's going to happen about packaging my CPAN
module Time::OlsonTZ::Data for OS distros.  I'm writing to (as far as I
can tell) the current Debian and Fedora maintainers of DateTime::TimeZone
packages, and I'm CCing the relevant perl.org mailing list.  We're now
getting close to replacing the current DateTime::TimeZone with a
rewrite that will use Time::OlsonTZ::Data as its source of Olson-derived
timezone data.


I only hope that close means summer or winter - not the busy periods.


This is a good question.

It's not like maintaining DT::TZ and updating it when there are new Olson 
releases is a big hassle, so I don't mind doing it for a while.


I think it'd make sense for Zefram and I to agree on a specific cutover 
date. Zefram has already released trial versions of DT::TZ with the new 
code that distros can use for testing and building new packages against.


I'll suggest September 1 as the cutover date when Zefram will release 
DateTime::TimeZone 2.00 using the new code base.


Does that seem reasonable?


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Olson querying

[Dave Rolsky]

On Sun, 4 Mar 2012, Zefram wrote:


As part of the plan for replacing DT:TZ, we discussed the need for a way
to list the available timezones, to replace the static DT:TZ:Catalog
document.  Attached is a prototype of a command-line tool that could
take this role.  I'd appreciate comments about its current operation
and about what it ought to additionally support.


The use of Date::ISO8601, Date::JD, and Time::Unix seems a bit odd. Can't 
you use DateTime to do all this stuff and avoid the additional prereqs? We 
can safely assume that anyone installing DateTime::TimeZone has DateTime, 
I think.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Error with the leap year

[Dave Rolsky]

On Sun, 4 Mar 2012, Michael G Schwern wrote:


Date math is not commutative and this leads to all sorts of problem.  They
cannot be dismissed as some silly authoritarian demand.


Indeed, it's not authoritarian. It's more like a nightmare inspired by the 
crack-addled madness of our calendar, plus the crystal meth inspired 
madness of DST changes, with a hint of LSD courtesy of leap seconds.


It's a bad fucking trip, and I've been on it for a long time.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

RE: Error with the leap year

[Dave Rolsky]

On Fri, 2 Mar 2012, jonathan.pey...@ubs.com wrote:


If that is what was decided, that's fine. However, it should be mentioned in 
the documentation.


A doc patch would be welcome.

However, I will point out that what you were doing is weird. If you want 
to do DateTime math, you need to use -add and -subtract (although these 
can _also_ come up with invalid datetimes in the face of DST changes). The 
DST issue is documented pretty clearly in the How Datetime Math Works 
section of the docs.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: rounder DT:TZ

[Dave Rolsky]

On Mon, 26 Sep 2011, auta...@urth.org wrote:

As to how and when these docs get generated, I don't really care, I just 
want the docs to be available after the distro is installed. If you want 
to do that as part of the install process that's fine.


Actually, thinking about this a bit more, I really think it's a good idea 
to generate it as part of building the distro. That way these docs will be 
available from metacpan.org and s.c.o.


It wouldn't be too hard to do this with Module::Build or dzil (or 
Module::Install, I assume).



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: rounder DT:TZ

[Dave Rolsky]

On Mon, 26 Sep 2011, Zefram wrote:


Dave Rolsky wrote:

Actually, thinking about this a bit more, I really think it's a good idea
to generate it as part of building the distro. That way these docs will
be available from metacpan.org and s.c.o.


That'll be even more out of date than generating it at install time,
if that's done in any distro other than Time::OlsonTZ::Data.  I'm not
inclined to put it there, because I'm not seeing the value in such
a document.


Right, so generate it there and just have DateTime::TimeZone::Catalog say 
see Time::OlsonTZ::Data::Catalog for a list of all zones.


The value is that it provides information on all the zones in various 
ways. That information isn't easily accessible on a system in any other 
way that I know of.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: rounder DT:TZ

[Dave Rolsky]

On Sun, 25 Sep 2011, Zefram wrote:


This is a total rewrite of DateTime::TimeZone.  The main purpose of the
change is that, as we've discussed for the past couple of years, it uses
DT:TZ:Olson (and thus the standard tzfiles) for Olson zones.  It ought
to be a drop-in replacement for the existing DT:TZ.  Please try it out,
to see if it actually succeeds as a replacement.  I'd particularly like
to know whether the new DT:TZ:Local code behaves itself on Windows, VMS,
HP-UX, and AIX.


First, thanks for working on this. I think getting this shipped will be a 
big improvement for DateTime users!


Now on to questions and criticisms ...



Why borg the Windows and HP-UX code into this distro instead of letting 
other maintainers handle this? For Windows, David Pinkowitz has said that 
he'd be willing to maintain a DT::TZ::Win32 distro, and we already have a 
separate HPUX distro.


I think this makes more sense since these maintainers have access to the 
relevant systems, and probably have more motivation to keep the code up to 
date.


If you borg it, you are stuck handling bug reports for systems you don't 
really know anything about.


As far as not automatically recognizing new OS-specific distros, that's 
fine since a new distro is an incredibly rare event.




If you want to document DateTime::TimeZone as not a class, I think having 
a documented DateTime::TimeZone::new function is really weird. It should 
probably be named something else, like load_zone (I don't really care, 
just not new.


Obviously, the old DT::TZ-new behavior would need to work too, but it 
doesn't need to be documented, and once this code is released, I can 
adjust DateTime.pm to use the new APIs.




This module breaks the DateTime.pm test suite. The failures look to be 
from some minor API differences. One of them was clearly a bug in the test 
suite (expecting 0 for a boolean instead of any false value). I've fixed 
that in HEAD, but the other failures seem to come from a change in an 
exception's error message.


The exception that's thrown for an invalid local time is different with 
this new version of the library. On one hand, I don't think this error is 
documented. OTOH, I don't see a reason to break anyone's code by changing 
this for no reason. Can you make the error the same in the new code? 
That'd be ideal.


-

The DateTime::TimeZone::Catalog module needs to exist, if only for 
documentation purposes. I think it'd make sense to add a generated 
Time::OlsonTZ(::Data)?::Catalog document to the Time-OlsonTZ-Data distro. 
This could just be a .pod file. Then the new DT::TZ can ship a Catalog.pm 
that just says see Time::OlsonTZ for a list of all zones.


---

Are there are any 32/64 bit issues we need to deal with? With the existing 
implementation, you can get time zone information for years after 2038, 
even though the system-installed Olson database doesn't go that far into 
the future. Yes, I know that information is basically meaningless, but I 
think in this case it's better to not throw an exception.


What happens if a user on a 32 bit system with a 32 bit Perl installs the 
Time::OlsonTZ::Data distro and tries to create a DateTime 100 years in the 
future in the America/New_York zone? I'm guessing it just works, but I'd 
like to know that for sure ;)




I think it also needs some docs on what's changed from an end user 
perspective. The big one is that in order to get Olson updates, the user 
now need to keep track of the Time::OlsonTZ::Data distro, not DT::TZ. That 
need a big flashing warning both in Changes and the main docs. I'll also 
make a big note of this when I release a DateTime.pm that depends on 
this new distro.


The COMPAT document you attached is good, but it's missing this key point.



I'd really like to see this code in a public repo before it's released, 
along with the various other modules this depends on. I'm fine with 
github, or I could host it on my own git server (which mirrors everything 
to github anyway). But if you put it on github yourself you'll own the 
canonical repos.


As far as maintenance, I would like to have comaint, although I'm not sure 
how much good that will really do me since all the real work is done in 
other distros anyway. But it'll make me feel better ;)



Thanks again for working on this.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Adding methods to DateTime.

[Dave Rolsky]

On Tue, 20 Sep 2011, Ben Tilly wrote:


Here is the obvious solution.

Create a subclass.  Use that in code you control.  In code you don't
control, you won't be calling those methods anyways...


Except if the code he doesn't control returns a DateTime object that he 
wants to pass into other code he controls.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DefaultFormatter for DateTime

[Dave Rolsky]

On Thu, 25 Nov 2010, pp wrote:


There is DefaultLocale in DateTime so I've thought that
that door is already opened.


I was young and stupid when I added this. Now I know better.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Locale::load

[Dave Rolsky]

On Sat, 20 Nov 2010, Bill Moseley wrote:


First, in load() there's this line:

die Invalid locale name or id: $name\n;

Can the newline be removed?  It's not that hard to track down, but it would
be nice to see where it's coming from.


That might be better as a croak anyway.


Second, is all locale information provided in the DateTime::Locale classes?
I guess my question is if we start supporting more languages in our app is
there other system-level language files that need to be updated other than
just DateTime?  (i.e. system locale packages).


What is all locale information? If you mean everything in the CLDR 
project, no, it's not even close. In fact, it's not even all the 
datetime-related info in CLDR.


I've been wanting to write a full Locale::CLDR module for a while, but my 
round tuits seem to have gotten lost in the mail.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Locale::load

[Dave Rolsky]

On Sat, 20 Nov 2010, Bill Moseley wrote:


We use Locale::Maketext in a web application (with language classes like
MyApp::I18N::en_us) and when a user selects a language a Locale::Maketext
handle is created for the request.  We also call DateTime-DefaultLocale(
$tag ) to localize formatted dates.

What happened was our translators added a new language file that didn't use
the correct language code, so that's when we saw the Invalid locale name or
id error.  That was fixed by just renaming the language file so the correct
code was used.   At least it made DateTime not throw an error.

But that made me wonder if there was anything additional required to support
the new languages on the server -- or if the fact that DateTime didn't
complain about the locale was enough. I.e. does our translation team need to
notify the team that manages the servers when a new language is added.


If there is a locale in DateTime::Locale for the id, then it will provide 
the same set of datetime localization information as any other locale.


Does that answer your question?


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: datetime question

[Dave Rolsky]

On Sun, 31 Oct 2010, Guustaaf Damave wrote:

I have been using caches for the searches for a while, and now of course we 
are in the middle of DST changes so I would like to ask you a question about 
that if you don't mind.


Is there a way to retrieve the next switchover time for a time zone? I could 
then store that in the cache and stop using that cache entry after that time, 
similar to how web browsers do that.


The relevant information is all in the DateTime::TimeZone objects, but 
there's no API for getting at it.


If someone would like to take a stab at coming up with a sane API for 
this, that'd be great. I think it'd be really useful.


It might be better to just expose some of the rawer data from the timezone 
objects and put the high-level API into a new module we could call 
DateTime::Event::TimeZone.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Anyone using DateTime::Fiscal::Retail454?

[Dave Rolsky]

I have some optimization I'd like to put in the next version of DateTime, 
but they break said module, which is doing some weird ugly stuff.


It'd be easy to fix, but the maintainer released just one version 4 years 
ago, so I'm guessing he's not too interested.


If anyone is actively using it, please consider asking the original author 
if he'd like a comaintainer.


If no responds back I'll probably do the new release in a week.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Converted datetime.perl.org to run on Silki

[Dave Rolsky]

I converted the wiki from Kwiki to Silki.

Silki requires each user to have a separate account. If you'd like to 
claim your edits, please let me know your username and I'll edit the 
account so you can use it.


This software has spam checking (which seems to sort of work ;), requires 
a log in to edit, and adds rel=nofollow to all links. Hopefully some 
combination of those will help keep spam down.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Converted datetime.perl.org to run on Silki

[Dave Rolsky]

On Tue, 28 Sep 2010, Jim Monty wrote:


Uh, not yet. I'm still getting HTTP 404 pages.


You'll have to give me a hint (send me the URI privately if it's the 
confirmation URI).



I've never before contributed open source software, written a Perl module, or
even submitted a patch. Well, there's a first time for everything, and today's
the day! I want to submit a patch to Silki. I think I've got rt.cpan.org figured
out well enough. I have a Bitcard ID. Now I just have a few questions:  Is there
a specific way to generate a diff? Must the before and after files be named
something specific? Do I attach it as a diff file? The CPAN FAQ is vague on
these points. (I'm using Microsoft Windows and the MKS Toolkit for diff, not GNU
diff.)


I know nothing about Windows tools, and this is getting OT for the list, 
but ...


rt.cpan is fine for me, each module author has different preferences.

In my experience almost everyone prefers unified diffs. You can diff any 
two files (that started off as the same file), so the names don't matter 
too much. It's often handy when patching a cpan distro to simply copy the 
entire distro, and then do a recursive diff between the original directory 
and the directory with your changes.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Wiki registration should now work

[Dave Rolsky]

If you tried to register and got an email that took you to a 404, just 
substitute datetime.perl.org for urth.org in the URI.


New registrations should just work from now on, and the email should 
include the correct hostname.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Format::W3CDTF bug

[Dave Rolsky]

On Sun, 26 Sep 2010, Gregory Williams wrote:


I'd be happy to give it to you. I don't really use it much myself.


If you have abandoned the module, I'll maintain it. Transfer permissions 
to me (GWILLIAMS) on pause, and I'll see about applying the patch and 
releasing a new version.


Doh, apparently I only have comaint. Daisuke Maki has primary, it seems.

Daisuke, can you give Gregory comaint?


Thanks,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Format::W3CDTF bug

[Dave Rolsky]

On Sun, 26 Sep 2010, Gregory Williams wrote:

Do you want me to completely take over ownership of the module or is 
there a way I should be looking to work with the existing DateTime svn?


I'll leave that up to Daisuke. If he doesn't want it either, he can give 
you primary.


As far as svn, if you'd like to move the module elsewhere, that's fine. If 
you want access to DateTime svn, tell me your Sourceforge account name.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Format::W3CDTF bug

[Dave Rolsky]

On Fri, 24 Sep 2010, Gregory Williams wrote:

I just posted a bug report to rt.cpan.org about a parsing problem with 
DateTime::Format::W3CDTF. After posting the report, however, I noticed 
that the same but was reported 5 years ago with a patch to fix the bug. 
Is this module being maintained anymore? My code relies on this module, 
and it would be great if the patch could be applied and a new version 
released in a timely manner.


Sounds like you're volunteering to maintain the module.

I'd be happy to give it to you. I don't really use it much myself.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime and bigint - we got a problem

[Dave Rolsky]

On Wed, 8 Sep 2010, Daisuke Maki wrote:


Parameter validation is also one of the bottlenecks when it comes to
using DateTime. I personally don't believe that removing Params::Validate
would make an application run faster, but at least I could silence some
of the nagging that I get when I recommend DateTime to others.

Would it be worthwhile to create a P::V free version of datetime in the repo
and see what it gets up?


Well, if you benchmark just DateTime, removing PV will definitely make it 
faster.


As you point out, this may not matter all that much in a given app, unless 
your app mostly consists of calls to DateTime methods that use PV.


But FWIW, I've been considering a DateTime v2 project using Moose, so I'm 
not really leaning towards _less_ validation ;)



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Duration or elapsed time in days?

[Dave Rolsky]

On Thu, 2 Sep 2010, Gabor Szabo wrote:


$d1 = DateTime-new(...);
$d2 = DateTime-new(...);

my $sec = $d2-subtract_datetime_absolute($d1)-seconds;
print $sec/60/60/24, \n;


  my $dur = $d1-delta_days($d2);
  print $dur-in_units('days');


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

RE: DateTime::Format::Strptime bug report

[Dave Rolsky]

On Thu, 2 Sep 2010, Metz, Bobby wrote:


-Original Message-
From: Metz, Bobby
# Grab the year either via exec or via DateTime, your choice
chomp(my $year = `date '+%Y'`);
# --or--
my $year  = strftime('%Y',localtime(time));


My apologies, I said using DateTime above but I used a POSIX example instead.

:D

DateTime could be used this way:

my $dt = DateTime-now();
my $year = $dt-strftime(%Y);


Or you could do the simple version ...

 DateTime-now()-year();


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Repo update

[Dave Rolsky]

I undid some of the dzil-ization and added a Build.PL.

It should now be possible to run tests from the working copy without 
having dzil installed.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Duration - Multiplication with a number less than one not working correctly

[Dave Rolsky]

On Sun, 22 Aug 2010, Dirk Joos wrote:


Am I doing something wrong or is it a bug?


Division just can't work. What is 1/25 of a month?

The individual units of a duration cannot be simply tranformed into other 
units, and the object doesn't support non-integer values, nor does 
DateTime.pm support non-integer values for datetime math.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime does not build from the repository

[Dave Rolsky]

On Mon, 16 Aug 2010, Tim Bunce wrote:


The Git::CommitBuild plugin can help:

http://search.cpan.org/perldoc?Dist::Zilla::Plugin::Git::CommitBuild

   Once the build is done, this plugin will commit the results of the
   build to a branch that is completely separate from your regular code
   branches (i.e. with a different root commit). This potentially makes
   your repository more useful to those who may not have Dist::Zilla and
   all of its dependencies installed.


This seems like the best solution, except I'm not using Git ;)

I'll look into implementing this for Mercurial.

(As an aside, we really need a set of VCI-based dzil plugins for this 
stuff so we don't have to reimplement the operations once per VCS).



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime does not build from the repository

[Dave Rolsky]

On Sun, 22 Aug 2010, Michael G Schwern wrote:


pokeCould you commit the Build.PL manually real quick to unblock
development?/poke  Yaks tend to be stubborn about being shorn and its silly
to sit on our hands waiting.


I made a branch called with-build-tools and checked in the entire build 
directory. But I really don't see how this is any different than you 
working from the tarball on CPAN. It's effectively the same result.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime::Duration - Multiplication with a number less than one not working correctly

[Dave Rolsky]

On Sun, 22 Aug 2010, Michael G Schwern wrote:


Or you allow fractional durations.  1 day / 1 hour = 1/24th of a day (not 1
hour).  Only when it is applied to a fixed datetime does it translate back.
Normally something like 2010-02-10 12:00 would become 2010-02-10 13:00
when 1/24th of a day is added.  But if the date were DST then it would do...
uhh... something I can't quite figure out just now.


What's the point of trying to do this? The result is confusing as hell in 
almost every possible case. What's (1 day / 97) for _any_ date?


I'm not sure why the original poster wanted this. The only good use case I 
can think of would be when you have a duration of seconds only and you 
want to divide it, in which case it's not that hard to do something like:


  my $new_dur =
  DateTime::Duration-new( seconds = int( $dur-seconds / 25 ) );

Or if you really want to get fancy, you could even turn the fractional 
portion into nanoseconds.


I think part of the problem here is that DateTime serves too many masters. 
I suspect there's a use for an object that's based on mjd and only uses 
seconds for scientific purposes.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime does not build from the repository

[Dave Rolsky]

On Mon, 9 Aug 2010, Michael G Schwern wrote:


Larger issues aside, how do you build this thing?


Use dzil. I removed the .shipit file, that was just legacy cruft.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Determining next DST transition

[Dave Rolsky]

On Fri, 23 Jul 2010, Elliot Merrony wrote:

To start from the beginning, I've been using the DT and DT:TZ modules for a 
world clock and want to add a feature which displays the time, date and 
effect of the next DST transition (if any) for each location.


The modules seem to allow me to do anything I could possibly imagine with 
times and time zones, except this. I realise I could test whether each 
location is on DST for every hour from now until 6 months ahead, but was 
hoping that there was a more elegant way of determining when the transition 
is.


Asking around, I was advised that the _rules attribute of an 
DateTime::TimeZone object returns an array of 
DateTime::TimeZone::OlsonDB::Rule objects which encode the start

and end of DST observances.

However, I'm now understanding from Dave's response to the bug that the 
_rules attribute neither is nor should be used for this purpose.


Any advice welcomed. Please bear in mind I'm a Perl beginner (I'm only using 
it due to the existence of these modules!) so apologies for any 
misunderstanding.


Basically, I think we could have a better API than returning the raw 
rules. Off the top of my head, I think a DateTime::Event module that let 
you ask for the next transition in a set would work well. Of course, that 
might still require opening up some chunk of the DT::TimeZone API, but I 
don't want to expose the raw _rules attribute directly.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTimeZone question

[Dave Rolsky]

On Fri, 23 Apr 2010, Jeison Rengifo wrote:


i have some problems with DateTimeZone class, i have an aplication in
windows server and it works fine, but i need to migrate to linux server
(hosting), and it doesn't work and i don't know why . can you help me
please.

Thanks

add source code

Best Regards

Jeison

function of_localtimetogmt($localtime,$timezone)
{
   $timezoneinfo = new DateTimeZone($timezone);
   $arraytime = $timezoneinfo-getTransitions();
   $i = -1;
   $indice=0;
   foreach ($arraytime as $transicion)
   {
$i++;
if($transicion['ts'] - $arraytime[$i]['offset']=$localtime)
 {
  $indice=$i-1;
  break;
 }

   }
   $newtime = $localtime-$arraytime[$indice]['offset'];
   return $newtime;
}


Uh, that looks like PHP code. You'll note that you wrote to datetime @ 
_perl_ dot org.


I'd suggest finding a list or forum that provides help with PHP.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: From the comp.lang.perl.modules newsgroup: Unicode::CLDR namespace

[Dave Rolsky]

On Tue, 6 Apr 2010, Jonathan Leffler wrote:


I dunno if anyone saw this message posted in compl.lang.perl.modules news group.
I'm not sure if it matters, but there was mention of Unicode and CLDR
recently, and just in case.


Actually, I've been talking to Philip via private email about the CLDR 
data. I have some work in progress on writing a proper, correct 
parser/data extractor for this module, as opposed to the hacktastic broken 
one currently used for DateTime::Locale.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

ANNOUNCE: DateTime::Locale 0.45 and DT::Format::Strptime 1.2000

[Dave Rolsky]

Please note that if you upgrade DateTime::Locale you should also upgrade 
DT::Format::Strptime or you will see a ridiculous number of warnings when 
using Strptime.

5~

DateTime::Locale 0.45   2010-03-19

- Installing this release will cause older versions of
  DateTime::Format::Strptime to warn like crazy. Please update
  DateTime::Format::Strptime if you install this release.

- This is an interim release still based on CLDR 1.7.1 pending the release of
  Locale::CLDR, which will happen real soon now, for some definition of soon.

- Removed dependency on Class::ISA and just copied what we need from said
  module directly. Class::ISA warns as deprecated if used with Perl 5.11.0,
  even though it works just fine (doh). RT #53940.

- All methods deprecated in the last release now warn when called.

- Added methods to return per-locale strftime formats from the glibc
  data. These methods are not yet documented. They are just there for now to
  allow me to update DateTime::Format::Strptime.

DateTime::Format::Strptime 1.2000 2010-03-19
- Updated to use non-deprecated DateTime::Locale API



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

How are people using DateTime::Locale directly?

[Dave Rolsky]

I'm planning to end-of-life DateTime::Locale sometime in the future, in 
favor of a new distribution, Locale::CLDR.


This new distro will be designed so that it can provide all the info from 
the CLDR project (eventually), rather than just datetime-related pieces.


My plan is to have DateTime use Locale::CLDR directly, rather than 
continue maintaining DateTime::Locale.


To that end, I'm wonder how people are using DateTime::Locale. I'm _not_ 
interested in people only using it via DateTime.pm. That form of usage 
will continue to work transparently. You specify a locale for a 
DateTime.pm object and you get localized output.


All of the information available from DateTime::Locale will be available 
from Locale::CLDR, although the API will be a little different.


In particular, is anyone out there using custom in-house locales at all?

That would be the biggest potential breakage point, since upgrading 
DateTime.pm to a version that uses Locale::CLDR will end up making your 
custom locales invalid.


I'm planning to support some form of custom locales in Locale::CLDR as 
well, of course.


None of this will happen in the very near future. I still need to get 
DateTime::Format::Strptime not using DT::Locale first, which is its own 
painful project ;)



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: How are people using DateTime::Locale directly?

[Dave Rolsky]

On Thu, 18 Mar 2010, Dave Rolsky wrote:

I'm planning to end-of-life DateTime::Locale sometime in the future, in favor 
of a new distribution, Locale::CLDR.


Actually, the more I think about it, the more I think I'll probably keep 
DateTime::Locale around.


I suspect that most of what it does will be delegating to a 
Locale::CLDR::Calendar object, but it will also include format data 
extracted from the glibc locale data files for the benefit of 
DT::Format::Strptime.


However, I don't really want to continue supporting the existing custom 
locale/registration/etc system for DateTime::Locale.


That sort of thing will probably move to Locale::CLDR or go away entirely. 
You can always simply instantiate a custom object and use it instead of an 
id.


So I still want to know if anyone uses custom locales.


Thanks,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Moving my modules to my mercurial repo

[Dave Rolsky]

Just a heads up that I'm sick of sourceforge's slow-ass svn, so I'm going 
to be moving my modules over to my Mercurial repo on my own server, 
http://hg.urth.org/


I'll probably move them over slowly as I do releases.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Error for module DateTime

[Dave Rolsky]

On Wed, 10 Feb 2010, Birane Seck wrote:


I get this error to install DateTime modul

Non-zero exit status: 2
 Parse errors: No plan found in TAP output
Files=43, Tests=3,  4 wallclock secs ( 0.29 usr  0.08 sys +  3.17 cusr  0.52 
csys =  4.06 CPU)
Result: FAIL
Failed 42/43 test programs. 2/3 subtests failed.
make: *** [test_dynamic] Error 2
 /usr/bin/make test -- NOT OK
Running make install
 make test had returned bad status, won't install without force


Please i need help


Please rerun the tests with verbosity on ...

  ./Build test verbose=1

Then send the complete output.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Does event fall within weekly recurring range?

[Dave Rolsky]

On Sun, 3 Jan 2010, James E Keenan wrote:


I went ahead and modularized the program.

You can get it from CPAN: 
http://search.cpan.org/dist/DateTime-Subspan-Weekly/


Or get blead from github:  http://github.com/jkeenan/datetime-subspan-weekly

Feedback still welcome.  Thank you very much.


Since it doesn't really fit in with the standard DateTime APIs, I'd prefer 
that it have a DateTimeX prefix.


Otherwise it looks good.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

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

[Dave Rolsky]

On Sat, 26 Dec 2009, Rick Measham wrote:

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.


I'm going to take co-maint, at least for the next release. Primarily, I'm 
interested in removing the dependency on deprecated DateTime::Locale 
features. This will probably just involve moving some of that code 
directly into DateTime::Format::Strptime itself.


After that, I'm open to more changes.

If we can produce something that's API-compatible with the current code 
that uses POSIX underneath, _and_ it's cross-platform, that's fine with 
me.


Thanks for all your work on this module over the years, Rick.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime-Locale-0.44

[Dave Rolsky]

On Wed, 23 Dec 2009, Keith Thomas wrote:


Your tar file is not dropping the files into their file paths - its just
dropping them all in the root of whatever folder you extract to and
generating empty folders for where they should go. Please fix it!


Uh, no it isn't.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Taking over DateTime::Format::Strptime?

[Dave Rolsky]

Rick, are you out there?

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.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Potential DateTime DOS Attack

[Dave Rolsky]

On Thu, 17 Dec 2009, Zefram wrote:


Almost.  In principle, the DT:TZ way of working handles far future dates
slightly better.


I'd actually say this doesn't matter. Look at how often time zone 
definitions change. Looking at America/Chicago, I see changes in 1974, 
1975, 1976, 1987, and 2007. That tells me that I should not count on 
_anything_ being the same 30+ years from now.


And the US is stable compared to some places.


To get a full DT:TZ-like service from DT:TZ:Tzfile, you need a layer or
two over it.  I don't want to bundle the Olson files with DT:TZ:Tzfile
itself: the module is for the single job of interpreting existing tzfiles.
But it'd be easy to produce a module that encapsulates a full set of
compiled tzfiles from Olson.  Slightly harder to produce a cleverer module
that automatically downloads the latest tzdata.  A module layered over
that could then use the tzfiles together with  DT:TZ:Tzfile to provide
the full Olson timezone service.  And DT:TZ can then be reimplemented
to use *that* as the basis for the geographic timezones.


I don't think you need auto-downloads. People download a new DT::TZ when I 
release one, or they don't. No one's complained about that.


The real question for me is whether the generated binary data will be 
cross-platform compatible. Are there any 32/64 bit issues? Endianness?


As long as they are cross-platform and the files can be distributed via 
CPAN, I think switching to this approach would be fine.



No one (that I recall) has asked for Posix or binary file support,
so making them dependencies seems like overkill.


Regarding asking for binary file support, I meant no one seemed to care 
about using their existing binary files.


If DT::TZ depended on DT::TZ::OlsonData that would be fine.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Potential DateTime DOS Attack

[Dave Rolsky]

On Wed, 16 Dec 2009, Michael G Schwern wrote:

Give me something to work with here.  Some insight into what and why DateTime 
is doing what its doing.  Is there a reason that DST info has to be generated 
linearly?  Would it be difficult to hold off on generating time zone info 
until its needed?  Are there instructions somewhere for dealing with the 
Olsen database?  SOME sort of discussion about how to solve the problem 
rather than the ways to paper over it.


I've thought about this a bit, and one solution I came up with was 
something like this ...


When generating the time zone data, we know that after a certain point, 
there is either one rule in effect (zone without DST or with permanent 
DST), or two rules in fixed alternation.


Either way, we generate a subroutine that determines the current time zone 
data (which is referred to as a span internally, as in a span of time 
during which a specific rule is in effect).


For the one-rule zones, this is trivial. Just return the data for the last 
rule.


For the two-rule zones, this should be calculable mathematically.

In both cases, we can simply not store the generated data, ever. The 
generated files already include pre-calculated data for the next 10 years. 
We could increase that to 20, and simply leave it at that.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Potential DateTime DOS Attack

[Dave Rolsky]

On Tue, 15 Dec 2009, Michael G Schwern wrote:

I know efficient 64 bit local time calculations are possible because the 
standard C library does it.  Its not because its written in C, its because 
its using a non-O(n) algorithm.


Fantastic. So I can expect a patch some time soon then?


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Paging Rick Measham re: Strptime

[Dave Rolsky]

Hi, Rick,

I wrote to you a few times privately but maybe I have the wrong address.

Are you still maintaining Strptime? I have some changes for 
DateTime::Locale pending that would break Strptime, so I'd like to get 
Strptime fixed up first.


Are you out there?


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Error with local time in one class only

[Dave Rolsky]

On Tue, 10 Nov 2009, Dan Horne wrote:


On Tue, 10 Nov 2009, Dan Horne wrote:

The die { found = 1 }; instruction sets $@ tp HASH(0xac2a148) at 
/usr/local/lib/perl5/site_perl/5.10.0/DateTime/TimeZone/Local/Unix.pm line 
115 and hence there is never a $...@-{found}.


What version of DT::TZ? As of 0.92, all uses of $@ should be cleanly 
local-ized before they are used, so they shouldn't be leaking.


I'm using 1.03. $@ is indeed localised. I don't think anything is leaking. It 
seems to me that $@ is simply stringyfying the hash, and appending the line 
number where the error is occurring (i.e. line 115), but I don't know why. 


Why it works for some calls and not this particular instance, I'll never 
know. After bashing my head trying to solve the problem for a couple of 
days, I have a simple workaround which is undoubtedly more efficient 
anyway, but which doesn't solve the underlying problem:


our $TZ = DateTime::TimeZone-new( name = 'local' );
sub now {
my $self = shift;
return DateTime-now(time_zone = $TZ);
}


This is a really good idea _anyway_. Calculating the local time zone is 
slow, and it's really unlikely to change over the lifetime of your app. 
Calculate it once and cache it.




Indeed. The workaround is sufficient for my needs. And if no one cares about 
why the problem is occurring (why it arises when one module calls 
DateTime-now but not others), I'm more than happy to let things go!


I'd love to fix it, but I can't without a recipe to reproduce it. I 
suspect the call to -now is a red herring. That code path doesn't do 
anything special with regards to timezones. It probably has something to 
do with _your_ code that's around the call to -now and 
DateTime::TimeZone.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Error with local time in one class only

[Dave Rolsky]

On Wed, 11 Nov 2009, Dan Horne wrote:

ient for my needs. And if no one cares about why the problem is occurring 
(why it arises when one module calls DateTime-now but not others), I'm 
more than happy to let things go!


I'd love to fix it, but I can't without a recipe to reproduce it. I suspect 
the call to -now is a red herring. That code path doesn't do anything 
special with regards to timezones. It probably has something to do with 
_your_ code that's around the call to -now and DateTime::TimeZone.




Oh, I'm sure I'm doing something wrong. But it's something that causes 
DateTime's now to fail only in the context of how I use it. I know it fails 
in DateTime::TimeZone::Local::Unix because I've stepped though the code using 
the Perl debugger, and I've gone right to the line where it fails (127, after 
trapping the die on line 115). I also know that it only fails if I invoke my 
class from a web app. If I call it from a simple script, it doesn't fail 
either.


I don't think it's necessarily a bug in your code. I'm just saying the 
problem lies in the interaction between your code and DT::TZ, and probably 
has nothing to do with DateTime-now().



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Error with local time in one class only

[Dave Rolsky]

On Tue, 10 Nov 2009, Dan Horne wrote:

The die { found = 1 }; instruction sets $@ tp HASH(0xac2a148) at 
/usr/local/lib/perl5/site_perl/5.10.0/DateTime/TimeZone/Local/Unix.pm line 
115 and hence there is never a $...@-{found}.


What version of DT::TZ? As of 0.92, all uses of $@ should be cleanly 
local-ized before they are used, so they shouldn't be leaking.


Why it works for some calls and not this particular instance, I'll never 
know. After bashing my head trying to solve the problem for a couple of days, 
I have a simple workaround which is undoubtedly more efficient anyway, but 
which doesn't solve the underlying problem:


  our $TZ = DateTime::TimeZone-new( name = 'local' );
  sub now {
  my $self = shift;
  return DateTime-now(time_zone = $TZ);
  }


This is a really good idea _anyway_. Calculating the local time zone is 
slow, and it's really unlikely to change over the lifetime of your app. 
Calculate it once and cache it.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Inconsistent bug with delta_ms, add, and time zones

[Dave Rolsky]

On Tue, 3 Nov 2009, Ronald J Kimball wrote:


Dave Rolsky wrote:
Sometimes DateTime::TimeZone thinks your local time zone is UTC. I have no 
idea why it'd would be doing this. You could hack up a local copy of 
DateTime::TimeZone::Local::Unix and have it spit out everything it's doing 
and what it finds.


Either it's doing something wrong or your system is very oddly configured.


I've discovered that, on this system, although /etc/localtime is a copy of 
/usr/share/zoneinfo/America/New_York, /etc/timezone contains 'Etc/UTC'.  I 
presume that qualifies as an oddly configured system.  :)


That is a bit weird.

I'm not sure why sometimes DateTime::TimeZone::Local would be getting the 
time zone from /etc/localtime and other times from /etc/timezone, though. 
Perhaps the call to File::Find::find() in 
DateTime::TimeZone::Local::Unix::_FindMatchingZoneinfoFile is failing 
intermittently?


That seems unlikely. The order of the checks in DT::TZ::Local is static, 
and there's no reason the find should fail sometimes and not others.


As someone else pointed, does intermittent really mean when run from 
different environments?


Is it possible that sometimes when the code is run it can't actually read 
/usr/share/zoneinfo for some reason?



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Inconsistent bug with delta_ms, add, and time zones

[Dave Rolsky]

On Mon, 2 Nov 2009, Ronald J Kimball wrote:

When I get the wrong result, the first DateTime object has its time zone set 
to UTC, rather than to America/New York (my local time zone).


The object is created like so:

 my %tmp;
 @tmp{qw/ year month day hour minute second /} =
   $current_delivery_date =~ /(\d+)/g;
 my $dt = DateTime-new(%tmp, time_zone = 'local');

Then, I check the name of the time zone with:

 $dt-time_zone-name

and sometimes it's UTC.

Do you have any guesses as to why this could be happening?


Sometimes DateTime::TimeZone thinks your local time zone is UTC. I have no 
idea why it'd would be doing this. You could hack up a local copy of 
DateTime::TimeZone::Local::Unix and have it spit out everything it's doing 
and what it finds.


Either it's doing something wrong or your system is very oddly configured.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: timezone-related bug in DateTime::Format::W3CDTF?

[Dave Rolsky]

On Thu, 29 Oct 2009, Pete Hodgson wrote:

Ever since British Summer Time ended in the UK last week my application 
has been seeing a very interesting bug. Here's an isolated perl script 
which demonstrates the issue:


This is a known bug - see 
http://rt.cpan.org/Public/Bug/Display.html?id=22802


I've emailed the maintainer to see if he still wants ownership of the 
module. If not, I'll probably apply a few patches and make a new release.


BTW, if anyone else out there wants to maintain this module, please let me 
know.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Inconsistent bug with delta_ms, add, and time zones

[Dave Rolsky]

On Fri, 23 Oct 2009, Ronald J Kimball wrote:

I have a subroutine that uses two DateTime objects.  It calls delta_ms() to 
get the delta between the two objects, does a bit of math, then calls add() 
to add the delta to one of the objects.  Although both objects are created 
with time_zone = local, occasionally the result is 4 hours ahead of what I 
expect (which would correspond to UTC).


Can you break this down to a _much_ smaller example that demonstrates the 
problem (ideally, just 2-4 lines)? I'm too lazy to wade through all the 
irrelevant code here.


Also, since this probably time zone related and we probably don't share 
your local time zone, please set the zone explicitly in your example code.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

ANNOUNCE: DateTime 0.51

[Dave Rolsky]

0.51   2009-11-01

- Switched to Module::Build. To force a non-XS build, start the build
  process with perl Build.PL --pp.

- POD-related tests are only run for the maintainer now.

- Fixed handling of negative years in CLDR formatting for y and u
  patterns. Note that the LDML spec says nothing about how this should work,
  so I took my best guess.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

ANNOUNCE: DateTime::TimeZone 1.01

[Dave Rolsky]

1.012009-10-19

- This release is based on version 2009o of the Olson database. This 
release has changes for Pakistan and Bangladesh. In addition, I have also 
applied the Argentina patch again, as this has not been incorporated into 
the official Olson data yet.


- The t/04local.t test file will be skipped on HPUX, which is a very weird 
system.


- When installing this module on HPUX, it now adds 
DateTime::TimeZone::HPUX to its prereqs so you can determine the local 
time zone.




-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

ANNOUNCE: DateTime::TimeZone 1.00

[Dave Rolsky]

1.002009-10-17

- This release adds a patch from Debian (http://bugs.debian.org/551195) 
for Argentina. Argentina's idiotic government decided to change their DST 
rules with two days notice. Pointer to patch from Gregor Herrman. Fixes RT 
#50590.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Next version of DateTime::Locale will have deprecation warnings

[Dave Rolsky]

All of the methods listed as deprecated in 0.44 will now start issuing 
warnings.


I've written to Rick Measham because this actually breaks the Strptime 
tests, but if anyone else out there is using these methods, now is the 
time to update your code.


I'll probably upload the new version in the next week or two, or as soon 
as Rick uploads a new Strptime, whichever comes first.


All of the changes are checked into svn 
at 
https://perl-date-time.svn.sourceforge.net/svnroot/perl-date-time/modules/DateTime-Locale/trunk



Dave Rolsky
Compassionate Action for Animals - http://www.exploreveg.org/
VegGuide.Org - http://www.vegguide.org/

Re: ANNOUNCE: DateTime::Locale

[Dave Rolsky]

On Sun, 13 Sep 2009, Vaclav Barta wrote:


On Saturday 12 September 2009 19:41:54 Dave Rolsky wrote:

Note that this release officially deprecates a lot of old methods. If you
are using (cough, Rick Measham ;) then please update your code.


We are many, :-) and looking at the POD, would it be possible to document the
argument to (month|day|quarter|era)_(format|stand_alone)_(wide|abbreviated|
narrow) - for example when it's optional? I wouldn't like to use an
unsupported call...


The docs for DateTime::Locale::Base get everything right. The docs on 
creating a custom locale subclass in DateTime::Locale are off, but will be 
fixed in the next release.


The list of deprecated methods in Changes is correct.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

ANNOUNCE: DateTime::Locale

[Dave Rolsky]

Note that this release officially deprecates a lot of old methods. If you 
are using (cough, Rick Measham ;) then please update your code.



0.44   2009-09-12

- All methods which return strftime-style patterns are officially
  deprecated (and have been a little broken for some time, regardless).
  This includes all date and time format methods ending in _format.

- Other deprecated methods include:
  date_parts_order, date_before_time
  era, eras
  month_name, month_abbreviation, month_narrow
  month_names, month_abbreviations, month_narrows
  day_name, day_abbreviation, day_narrow
  day_names, day_abbreviations, day_narrows
  quarter_name, quarter_abbreviation, quarter_narrow
  quarter_names, quarter_abbreviations
  am_pm, am_pms
  era_name, era_abbreviation
  era_narrow, era_names, era_abbreviations

- All of these deprecated methods will eventually be removed. If you are using
  them directly, please change your code.

- Converted data files in tools/t/test-data to Unix line endings. This works
  around a bug in Module::Signature. Reported by Zefram. RT #49085.

- Require Params::Validate 0.91, since 0.89 caused test failures for
  someone. Reported by Jeremy Hetzler. RT #41365.




Dave Rolsky
Compassionate Action for Animals - http://www.exploreveg.org/
VegGuide.Org - http://www.vegguide.org/

Win32 help for DT::TimeZone

[Dave Rolsky]

http://www.nntp.perl.org/group/perl.cpan.testers/2009/09/msg5285650.html

Anyone care to take a stab at figuring that out?


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Win32 help for DT::TimeZone

[Dave Rolsky]

On Fri, 11 Sep 2009, Jim Monty wrote:


The CLDR has this:

    
http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/windows_tzid.html

And here is its XML source named supplementalData.xml:

    
http://unicode.org/repos/cldr/trunk/common/supplemental/supplementalData.xml

So it seems there is a standard mapping of Microsoft Windows time zones 
to the Olsen tz (Zoneinfo) database, but that is isn't up-to-date enough 
for practical use. I guess this is the problem with trying to 
standardize the coupling of two non-standard things (well, one 
proprietary thing with another de facto standard thing).


Yeah, I'm aware of the CLDR data, but as you pointed out, it's not up to 
date. I think they play catch up too, just like us.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: Status of http://datetime.perl.org/

[Dave Rolsky]

On Wed, 2 Sep 2009, Jonathan Leffler wrote:


As of both last night (2009-09-01T22:30-07:00) and this morning
(2009-09-02T11:15-07:00), the http://datetime.perl.org web site is not
responding.
Does anybody know why?  Did I miss an announcement of its impending demise?


Doh, I forgot to get them to update DNS when I moved my server. I'll get 
it fixed.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

ANNOUNCE: DateTime::TimeZone 0.95

[Dave Rolsky]

0.952009-08-18

- Attempting to load an invalid Olson-style name like Bad/Name did throw 
an error since 0.92. Reported by Florian Ragwitz.


- Localized $SIG{__DIE__} for every eval.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

ANNOUNCE: DateTime::TimeZone 0.94

[Dave Rolsky]

0.942009-08-17

- This release is based on version 2009j of the Olson database. This
  release has changes for Egypt.

- Localize $SIG{__DIE__} in DateTime::TimeZone::Local, so errors in evals 
done
  by that module are not seen by existing __DIE__ handlers. Based on a 
patch

  from Jim. RT #48567.



/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/