Re: missing something..part 2
Or use DateTime::TimeZone::Alias [1]
(untested code follows)
use DateTime::TimeZone::Alias
for my $hr in (0 .. 12) {
DateTime::TimeZone::Alias->set("Etc/GMT+$hr", "-${hr}:00");
DateTime::TimeZone::Alias->set("Etc/GMT-$hr", "+${hr}:00");
}
# And don't forget the 15 minute offsets and the 30 minute offsets
# Also, the offsets may go bigger than 12... check to see what you
# have defined on your system
> > Hehe. I'm the DBA. And I've updated everything to most recent stuff,
> >but the boss man wants "generic time zones" in our list "just in case" a
He means the timezone database that is distributed with the perl
DateTime package, nor your (oracle/mysql/whatever) database.
-ben
[1]
http://search.cpan.org/~jhoblitt/DateTime-TimeZone-Alias-0.0501/lib/DateTime/TimeZone/Alias.pod
On Thu, Jan 25, 2007 at 04:18:02PM +, Zefram wrote:
> Matthew wrote:
> > Hehe. I'm the DBA. And I've updated everything to most recent stuff,
> >but the boss man wants "generic time zones" in our list "just in case" a
> >customer can't find his or doesn't realize his city is listed differently.
>
> Unlikely to ever occur. As far as anyone knows, the Olson zoneinfo
> database contains all currently-distinct timezones. (It explicitly aims
> to include all timezones that have been distinct at any time since 1970.)
> You might want to play with the tzselect(8) program, which guides one
> through selecting a geographical timezone from the database.
>
> -zefram
Re: Arbitrary Date Parsing [Was: Re: Date::Parse (Time::Local?) choking on years between 1956<->1938 and wrong below, on FC4/5.8.6]
On Fri, Jul 08, 2005 at 10:38:24AM +1000, Rick Measham wrote: > Scott R. Godin wrote: > >I'm sort of surprised that there is no equivalent DateTime-using module > >that would mirror the capabilities of Date::Parse. Dave, Have you talked > >with Graham Barr at all about merging the arbitrary-date-parsing > >capabilities (of Date::Parse) into the DateTime family tree? You can try my DateTime::Format::DateManip... It is just a wrapper that uses DateManip to parse the dates then it converts them to DateTime objects. As a fair warning, DateTime is a bit dodgy about the way it handles DST. (for instance if you are in DST and ask for a time in the non-DST portion of the year your time will be 1 hour off... e.g. if I ask for Jan 1 2006, 13:00 now then convert it to seconds since 1970 it will actually be Jan 1 2006, 12:00). Also if you have a long running process that has loaded DateManip and you have a DST change it will effectively ignore the change since the offset is cached at startup (you can force it to recompute at runtime, but it doesn't by default). -ben
Re: Latitude/Longitude to Olson timezone name
And to ask a nasty question... will it support localization? Or I suppose if your mapping is from lat/long to TZ then the localization problem will be in the code for taking a location name and producing the lat/long. Which makes this more tractable. -ben On Sun, Mar 28, 2004 at 05:52:41PM -0600, Ed Perrone wrote: > Thanks for all the suggestions. I have been looking through the Olsen > distribution files (zone.tab, etc.), and was considering making up a > conversion table. I just didn't want to re-invent the wheel if it had > already been done. > > >Now, as for "I need to figure out which of the Olsen zones "Austin TX" is > >located in.", I can offer a solution: Ask the user. > > Wel.. mebbe. But you have to assume the user is dumb and doesn't > know. :-) > > There is commercial software that does all this. It is the "International > Atlas," based on the Shanks time-changes books and published by the same > people. I don't know what system they use for their lookups -- probably > some sort of internal conversion table of the same type we're discussing > here. They charge mucho bucks for their software, especially for use in a > Web environment. > > Since no one has actually done it yet, I will go ahead and see if I can > make up some kind of a lookup/conversion table. (I'm apparently going to > have to do this anyway for my client's project.) I will make the results > available here, and if there's some way they can be integrated into > DateTime, I think it might make a lot of people happy. > > (Of course, that means such a table would have to be updated periodically, > to take into account political changes, etc.) > > Anyways, I will see what I can come up with and let y'all know. > > --- Ed > > > > Ed Perrone > Interactive Web Development > [EMAIL PROTECTED] > http://www.edperrone.com >
Re: DateTime::Stringify ...
Of course the overloaded stringification sub could look at its call stack and see who was calling it and skip stringification if it was Devel::StackTrace or Carp... But that is _really_ gross. -ben On Sat, Feb 21, 2004 at 04:01:39PM -0600, Dave Rolsky wrote: > On Sat, 21 Feb 2004, Matt Sisk wrote: > > > Hmmm, I guess not. At least, I couldn't get 'no overload' to do anything > > useful. > > > > How much of a PITA is it to use overload::StrVal and > > overload::Overloaded in Devel::StackTrace? > > Not a PITA at all, I just liked the other solution even more. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: DateTime::Stringify ...
If I remember correctly the argument against auto stringification was that it made debugging harder. I started on some generic way to add stringification to an object that couldn't. But never got past the 80% point (you kindly reviewed the code for me and provided nice comments). -ben On Sat, Feb 21, 2004 at 02:38:00PM +, Leon Brocard wrote: > Dave Rolsky sent the following bits through the ether: > > > Would you consider renaming this as DateTime::Util::Stringify? I'd like > > to avoid having lots of different second level namespaces under > > the DateTime TLNS (new acronym, you read it here first). > > > > Or you could try to talk me into adding this to DateTime.pm on the > > datetime list. I remember there was a reason I didn't want to do this, > > but I can no longer remember what it was ;) > > I wrote the module as I assumed that you had a reason not to put it in > the DateTime core. I don't really fancy renaming it into a namespace > that doesn't exist. Consider this a prod for open discussion about the > stringification of DateTime objects ;-) > > Leon > -- > Leon Brocard.http://www.astray.com/ > scribot.http://www.scribot.com/ > > ... Would you prepared if gravity reversed itself?
Re: DateTime::LeapSecond
I imagine that it must happen worldwide at the same time. Plus this is really a UTC thing (since leap seconds are what make UT into UTC), most people don't need that much accuracy and don't adjust their clocks... and anyway, most clocks are not accurate enough for it to matter. -ben On Mon, Jan 05, 2004 at 02:32:03AM +1100, Rick Measham wrote: > It seems that DateTime::LeapSecond adds the extra seconds at midnight UTC. > Two questions: > 1. Did it always do that .. I seem to recall that it used to add it > at midnight in the local time zone. > 2. Should it be at midnight UTC? I can't find anything that says one > way or the other but I can't imagine that I'm supposed to adjust my > clock by 1 second at 11am rather than midnight.
Re: "Calculate down time"
Why do you hate me :-) I have no idea how to handle this easily... is a bunch of sets the right answer? Seems gross. -ben On Mon, Oct 13, 2003 at 01:00:09PM -0300, Flavio S. Glock wrote: > How about a question for the FAQ? > > http://perlmonks.org/index.pl?node_id=298788 > > > > Calculate down time of devices in prime time (only working hours, excluding > > p_holidays) > > by albertc on Oct 13, 2003 at 05:00 GMT+3 > > > > I have up & down datetime data for devices, I need a function that will provide the > > downtime within the primetime period. Input will be d_time, u_time, stime > > (starting time > > for Primetime, 08:00:00), etime (endtime for PrimeTime, 18:59:59). The function > > also > > needs to remove downtime that occured on a public holiday and over weekends! Public > > holidays will be read from mysql table with Datetime record of each public holiday. > > > - Flavio S. Glock
Re: DateTime::TimeZone::POSIX
Not that I have seen. This would be tricky to do right. I don't think you can make arbitrary timezones easily. Ideally the "right" thing to do would be to parse the TZ string and find the Olsen entry that matches it, then use the Olsen ID. In the cases where that does not exist, then you would have to make a timezone object up that represents the rules for the TZ. Perhaps you can simply do this each time you parse a TZ... Nonetheless, I think being able to parse TZs would be a great thing for the DT project. -ben On Thu, Sep 25, 2003 at 12:49:00PM +0200, Claus Färber wrote: > Hallo, > > is someone working on a module that takes timezone strings from the > environment variable TZ as defined by POSIX: > http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html > > Claus > -- > http://www.faerber.muc.de
Re: Olson <-> Microsoft mappings
I agree with Joshua's intent. I think that the timezone selection right now is the most difficult part of using DateTime if the user has to specify it (and especially if you are not using a GUI). I agree that changing DT::TZ is probably not the right thing to do. Perhaps there should be a DT::TZ::Helper namespace? I would also love a module that would set up appropriate DT::TZ::Alias(es) for a given country. So if I loaded DT::TZ::Alias::Country qw(US); (or whatever) it would load EST as an alias for America/New_York. Finally, having the aliases US/Eastern makes a lot of sense to me. Perhaps it would make sense to make equivalent alises for all of the countries (possibly under a DT::TZ::Alias submodule). So for countries without different zones that is simply: China Britain Then for countries with multiple zones: Australia/Eastern etc. -ben On Mon, Sep 22, 2003 at 10:31:38PM -1000, Joshua Hoblitt wrote: > > It's become painfully obvious that having end users choose > > a timezone based on the huge list that is provided natively > > by DateTime::TimeZone::all_names just isn't very practical > > at this time. (Perhaps in the future when more people are > > used to dealing with the Olson names.) ..
Re: RFC: DateTime::TimeZone::LMT
No, I would like this too. Perhaps the functionality can be rolled into DT::Alias somehow. They seem related... -ben On Tue, Aug 12, 2003 at 08:02:02AM +1000, Rick Measham wrote: > > What do people think? I can provide patches for this if I'm not the only > one who'd find it useful.
Re: DateTime Performance
On Mon, Aug 04, 2003 at 10:10:54AM -0400, John Siracusa wrote: > > Does it need to do that? I mean, sure, eventually it might have to do that > if I want to do some sort of date manipulation, or even just fetch or print > the date. But does it have to really do anything at all during object > construction other than stash the args somewhere? [...] > What about what I mentioned earlier: lazy (or "lazier") evaluation in the > constructor? Basically, I want construction with known values to be as fast > as possible since there's a chance I may not even look at the date fields of > my objects. But it's a hassle to have special-case code that either doesn't > fetch or doesn't set the date fields of my objects, just so I can avoid the > relatively expansive calls to DateTime->new() Why not make your module be lazy about whether or not it creates a DateTime? It seems to me that 99% of the time you want to do more than simply create a date and not do anything else with it, in which case you need to parse the date sometime. Since making DateTime lazy will probably mean extra cost (in terms of overall CPU usage and complexity) it seems like this is not a useful tradeoff. Also, you may not be able to validate the arguments without doing some of the processing and deferring a potential error until later seems like it would lead to confusion. -ben
Re: long/lat -> timezone map
I think it would be useful to make a set of TZ aliases per country... like the US/Eastern, etc. stuff but for every country. It would be even more useful to be able to break it down further as needed (state by state and county by county as needed). But that is a lot of work. -ben On Fri, Aug 01, 2003 at 10:05:12AM +1000, Rick Measham wrote: > At 9:42 AM +1000 1/8/03, Iain Truskett wrote: > >Does anyone know of a machine-readable "map" that can convert lat/lon > >to timezone? > > Mac uses a map, you click on the map and it tells you the time at > that place in the world. Of course it's closed source so we can't get > a copy of it :( > > I remember that this was asked somewhere else .. here or someplace > else. There's an online map at http://www.worldtimezone.com/ but it's > not 'clickable' to select a timezone. > > While converting a lat/lon to a timezone would be close to > impossible, I'm willing to work on a clickable HTML or Flash map. > > The problem with converting lat/lon is that countries are not > geometric shapes where it would be easy to determine if a particular > lat/lon is within that country. > > Cheers! > Rick > > -- > > There are 10 kinds of people: > those that understand binary, and those that don't. > > The day Microsoft makes something that doesn't suck > is the day they start selling vacuum cleaners > > "Write a wise proverb and your name will live forever." >-- Anonymous >
Strange errors when trying to fix DateTime::Event::Nameday
Ok, I am trying to fix the broken tests in DateTime::Event::NameDay
and am getting the error 'Span cannot start after the end in
DateTime::Span->from_datetimes'. However my span looks perfectly
valid...
So I boiled it down to a simple test case:
--
#!/usr/local/lib/perl -w
use strict;
use DateTime;
use DateTime::Span;
use DateTime::Calendar::Christian;
my $dt1 = DateTime->new
( year => 1752,
month => 1,
day=> 1,
);
my $dt2 = DateTime::Calendar::Christian->new
( year => 1755,
month => 1,
day=> 3,
reform_date => $dt1,
);
my $sp = DateTime::Span->new(start => $dt1, end => $dt2);
--
This gives me two types of error:
--
Use of uninitialized value in numeric ne (!=) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/DateTime.pm line 1174.
Use of uninitialized value in numeric comparison (<=>) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/DateTime.pm line 1174.
Span cannot start after the end in DateTime::Span->from_datetimes
--
What am I doing wrong? (This is using the latest CVS versions of
things) and the relevant lines from DateTime.pm are:
-- (> marks line 1174).
foreach my $component ( qw( utc_rd_days utc_rd_secs rd_nanosecs ) )
{
>return $dt1->{$component} <=> $dt2->{$component}
if $dt1->{$component} != $dt2->{$component};
}
--
Thanks,
-ben
Re: Python's 'DateTime'
DateTime::Display::Calendar or DateTime::Display::Calendar::Text (vs. HTML, etc.) ? -ben On Tue, Jul 29, 2003 at 10:46:59PM -1000, Joshua Hoblitt wrote: > > Months ago I posted the beginings of a module that I called > > DateTime::Format::Calendar. The discussion that followed was that > > 'format' was the wrong namespace, but the conversation ended there. > > (http://nntp.x.perl.org/group/perl.datetime/2488) > > > > I'm happy to continue working on this, and will upload it somewhere, but > > I need a name. > > DateTime::Calendar::Gregorian::Month? > > -J > > --
Re: ANNOUNCE: DateTime 0.14
On Mon, Jul 28, 2003 at 07:04:12PM +0200, Eric Cholet wrote: > Dave Rolsky wrote: [...] > >But don't latin-1 and utf8 overlap for the first 255 chars anyway? > > No they don't. Common misconception it seems. To clarify, UTF-8 and ASCII overlap, but any character with the high bit set incicates that this is a multi-byte character in UTF-8 so the extended characters in latin-1 can not match. However, the first 255 characters in Unicode overlap with Latin-1, but that is not really helpful since you are either using UTF-8 or a constant multi-byte encoding and need to add the extra bytes... -ben
Re: DateTime::Locale::en_US
en_US is root... everything else inherits from that. So when you use the factory to create the class it will be created correctly (at least it did when I was last testing my code, I haven't installed the latest version). Note that the classes implementing the locales are often sparse and inherit from parents so they need not define all of the methods defined in the DT::L::Base POD, if they or a parent omits it it will eventually come from the root.pm. -ben On Sat, Jul 26, 2003 at 04:01:22PM -1000, Joshua Hoblitt wrote: > > There is no DateTime::Locale::en_US in the CPAN > > version. Is this a bug or I'm using it the wrong way? > > It's a bug. Theres even a locale alias that tries to point at it. > > 'eng_US' => 'en_US', > > en.pm seems to be missing as well as there's an alias for it as well. > > 'eng' => 'en', > > There's probably others missing as well. The icu data for en and en_US isn't > missing so it's not immediately clear to me what the issue is. > > -J > > --
Re: icu-xml parser deadlocks
RH 9.0. I wonder if it your locale and unicode slowing everything down... I set my default locale to en_US (not ustf8) a while ago. -ben On Fri, Jul 25, 2003 at 07:02:14AM -1000, Joshua Hoblitt wrote: > > Me too: > >This is perl, v5.8.0 built for i386-linux-thread-multi > > > >Linux ayup.limey.net 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003 > >i686 athlon i386 GNU/Linux > > > > -ben > > So that Redhat - What version of the dist? I'm on Gentoo 1.4rc2. > > For me the parser makes it to: > > af > af_ZA > (race condition - hangs forever) > > Interestingly - if I run it through the debugger it does make some progress. It's > taken about 8 hours to make it to 'ms'. > > I've reinstalled just about everything applicable from CPAN. I wonder if it's a > problem with some c library in the dep. chain. > > -J > > --
Re: icu-xml parser deadlocks
Me too: This is perl, v5.8.0 built for i386-linux-thread-multi Linux ayup.limey.net 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003 i686 athlon i386 GNU/Linux -ben On Fri, Jul 25, 2003 at 02:17:23AM -0500, Dave Rolsky wrote: > On Thu, 24 Jul 2003, Joshua Hoblitt wrote: > > > I still can't get DT::Locale's parser to run under Linux (seems happy > > with Solaris thou). Has anyone else tried this under Perl 5.8.0 on > > x86/Linux? > > Works for me with that exact setup. > > > -dav > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: DateTime::Format::Common questions...
I committed it this afternoon (just the Locale change not the Common parser). -ben On Tue, Jul 22, 2003 at 11:27:13AM -1000, Joshua Hoblitt wrote: > > > 2) Can I add the sub _date_parts_order to the locales? I have the > > > patch to generate_from_icu that does this if you want to see it. > > > > Sure, go ahead, but make it "date_parts_order". It'll be public, after > > all. > > And I need it for DT::F::DB2 as DB2 is locale sensitive. > > -J > > --
Re: DateTime::Format::Common questions...
On Tue, Jul 22, 2003 at 11:36:13AM -0500, Dave Rolsky wrote: > On Tue, 22 Jul 2003, Ben Bennett wrote: > > > 1) Will DateTime 0.14 be the first release with locale support? If > > Yes, and yes. I'll be releasing this stuff soon, I think. Ok, in that case I will check it in with a dependency on .14 (which will mean that you can't install it without warnings for a little while). > > 2) Can I add the sub _date_parts_order to the locales? I have the > > patch to generate_from_icu that does this if you want to see it. > > Sure, go ahead, but make it "date_parts_order". It'll be public, after > all. Will do. > > > > 3) I think I need to have additional per-locale information > > So you plan to customize this for every locale? Ambitious. Well... No. :-) But I plan to have a way to set it for any locale and I will impose upon the nice people on this list who speak other languages to tell me the appropriate values for their locale. For ones we haven't done it will inherit the root locale value. I am also going to make a decent attempt to do the right things with the AM/PM and BC/AD strings. (And I will probably accept the English versions of those for all locales anyway). > > So, I propose to per-locale additional information. However, I am > > not sure if it makes sense to augment the DT::Locale files or to > > have a separate DT::F::C::Locale tree. It might be wise to allow > > for additional day and month name variations too. Obviously it > > should default to the DT::Locale stuff whenever possible. > > It almost certainly belongs in the DT::Locale code. I'll come up with a > way to hook in our extra data to the generation process. There's already > something in the generator to override the ICU stuff when it's wrong, so > it shouldn't be too hard. Ok, if you don't get to it I will take a look sometime. I assume that you want this to come from a separate source than the ICU data? Probably a new directory and file per-override? -ben
DateTime::Format::Common questions...
Okay, I have renamed the module to DateTime::Format::Common and I am getting ready to check in the rough version I have. However I have a few questions I want to get resolved first: 1) Will DateTime 0.14 be the first release with locale support? If so, when will you be bumping the version number (do you usually do that just before release?) I need that version of DateTime as a dependency. 2) Can I add the sub _date_parts_order to the locales? I have the patch to generate_from_icu that does this if you want to see it. Longer term questions (these can be resolved after an initial checkin): 3) I think I need to have additional per-locale information (i.e. AD/BC, AM/PM and now, today, and +- infinity). While AD/BC and AM/PM are in the current locale files I don't think they are in a useful form since there are too many permissible variations. So, I propose to per-locale additional information. However, I am not sure if it makes sense to augment the DT::Locale files or to have a separate DT::F::C::Locale tree. It might be wise to allow for additional day and month name variations too. Obviously it should default to the DT::Locale stuff whenever possible. Thoughts? -ben
Date formats and strptime...
DateTime::Locale defines 4 lengths for dates and times (full, long,
medium, and short), defines which date format length is the default
one and which time one is the default. It also defines whether the
date preceeds the time or not.
With all of this info, I think it would be nice to be able to use it
to print the locale appropriate "default datetime string" as well as
the "default date", default time" and all 4 lengths for both date and
time.
Does it make sense to add methods to DateTime to allow for this, or is
it a separate class? My argument for adding it to DT is that if they
are methods on the DT object then you can use strftime to print them
in conjunction with other info (but I am not sure if that is really
useful).
It would be really nice to be able to automatically parse one of these
generated strings using DT::F::Strptime, The gotcha there is that a
bunch of the formats end up being mapped to method calls on DateTime
(e.g. %{day}) and as far as I can tell those are not yet supported.
Obviously we would not be able to parse arbitrary methods, but we
could at least add support for the core DT ones.
As a final question, is it a security hole that we allow method calls
on a DT object from strftime strings? Since we are not passing
arguments I think all of the methods that could be called are pretty
safe. Also I assume that you will not be getting strftime format
strings from unsafe sources, but I figured it was worth mentioning.
Thanks,
-ben
Name for DateTime::Format::Simple
I am not a big fan of DateTime::Format::Simple either. My best suggestions are: DateTime::Format::Basic Common Generic Localized Can anyone come up with anything better? -ben
Very rough DateTime::Format::Simple
Sorry this is such a dense post, but this module spawned a lot of discussion and deciding what a simple format turned out to be not so simple. Anyway, if you want to play with this, make sure you look at the note about regenerating the DT::Locale data. If people are okay with the general direction of the code then I will commit it to CVS (I would like to get some consesus on the name, but will start a separate thread for that). Available from: http://www.limey.net/~fiji/perl/DateTime-Format-Simple-0.01.tar.gz http://www.limey.net/~fiji/perl/generate_from_icu (see Notes) Notes: - I use the locale to determine the meaning of \d\d-\d\d-\d\d. It can be ymd, dmy, or mdy. In order to make this work the DT::Locale tools/generate_icu needed a small change. Get the script above and re-run the generator. If this change meets with approval I will commit it. - If the length of the year is <= 2 then I will use the base_year argument (defaults to the current year) to work out the appropriate century: my $base_century = int( $base_year / 100 ) * 100; $year += $base_century; $year -= 100 if $year - $base_year > 50; Major ommissions: - No POD - AM/PM & BC/AD are not localized - BC/AD is not supported at all yet (neither are negative years) - Only tests English and French(?) parsing - Needs many more tests and in more languages (I actually need fluent speakers to tell me if the formats it parses are reasonable) Interface: - Only the DT::F::Simple->parse_datetime( ... ) at the moment, I will add a new() and the ability to call through the returned object - The ... can either be a single argument giving the string to parse OR name => value pairs: string: The string to parse locale: The locale to parse in (assumes root which is en_US) time_zone: The default TZ of the returned DT object (if no TZ is specified in the string), defaults to 'floating' base_year: The year to use if the string does not specify one, defaults to the current year, also gives the point to use when inferring a complete year from a 2 digit one... debug: If true then it will print lots of info, defaults to false Formats it should be able to parse: - ISO8601 date (only in the format -MM-DDTHH:MM:SS.). The T separator is optional and may be replaced by 0+ spaces. The time may be ommitted from the rightmost part to the left (all of the date must be given). The separators inside the date and time (i.e. the -s and :s are also optional) - HH:MM:SS.FFF AM/PM is parsed, again the highest precision parts may be ommitted. AM/PM is optional, if not present it assumes 24 hour time. You may specify HH AM/PM, but in this case the AM/PM is required. - Dates of the form Y+/M+/D+ with -, . or / as the separator. Also accepted are M/D/Y or D/M/Y depending on the locale. (Y/M/D is assumed of the first number is longer than 2 digits or the locale explicitly calls for YMD) - DD-MonthName-Y+, where Month name is the locale appropriate string - DD MonthName or MonthName DD with a year somewhere else in the string - If there is a locale appropriate day name somewhere in the string it is used to validate the parsed date. - Timezones are supported either as GMT offsets: GMT+5:00, +5:00 Only supports offsets from GMT or UTC, the : is optional, and you may omit minutes, you may also provide seconds, but they must always be 00. - Named time zones are fine, it will check against the current set of DT::TZ names (at runtime, so aliases are honored) - You may use both offsets and parenthesized named TZs, so '-0600 (CST)' will work (assuming an alias for CST). - It will ignore accents in languages when parsing the strings. Please help: - I am desperate for speakers of other languages to provide me with good test strings! - If you want to mail me with more English test strings that would be great - Suggestions of additional formats to parse would be greatly appreciated Thanks for bearing with me! -ben
Re: RFC: DateTime::Complex
What were your thoughts on the constructor? I think people expect a
new, but are unspecified things 0 (like DateTime) or undefined?
Also, what happens when you compare dates (or is that simply not
defined?).
Now that I think about it, you will probably need contains,
intersects, etc. But I assume you already planned that.
For the name, my thoughts are:
DT::Partial
DT::Incomplete
DT::Reduced
Is it useful to have an optional base DT that can be used when an item
is undefined (to more easily allow Time only objects):
--
my $dtw = DateTime::Whatever->new
(hour => 10, minute => 5, second => 2);
my $dt = DateTime->new(year => 2003, month => 7, day => 18);
$dtw->set( base => $dt );
print $dtw->year; # 2003
--
If you do that it may also be useful to have a method fix() (or
get_datetime() or flatten() or something) that returns a DateTime
either using the current base datetime, a provided datetime, or now()
(perhaps today()). This would make it convenient as a the thing to
return from formats where there can be missing information:
--
...
my $dt = DateTime::Format::Whatever->parse_datetime("12:30")
->flatten();
...
--
Or am I off my rocker?
-ben
On Fri, Jul 18, 2003 at 12:54:55PM -0300, Flavio S. Glock wrote:
> Yes, this is better:
>
>$dtc1->set( month => 12 );
>$dtc1->set( month => undef );
>
> It can work without cloning, in order to be compatible with DateTime
> API.
>
> Name - how about DateTime::Whatever ? (I like it)
>
>$date = DateTime::Whatever->whatever( year => 2003 );
># 2003-xx-xxTxx:xx:xx
>
>$date = DateTime::Whatever->new( year => 2003, day => undef )
># 2003-xx-01-T00:00:00
>
> And this is one of the lines I snipped from the previous mail:
>
>$date->add( months => 12 )
># 2004-xx-01-T00:00:00
>
> - Flavio S. Glock
>
>
> Ben Bennett wrote:
> >
> > I like the idea (this is the partial date & time thing right?) but I
> > am not too sure about the name... unless you start dealing with times
> > with real and imaginary parts :-) (Not that I have any suggestions for
> > a name yet).
> >
> > Regarding the interface would it be better to have:
> > --
> > my $dtc1 = DateTime::Complex->new_undef();
> > # I assume that DT::C->new() assumes 0 like DT->new()
> > # but that DT::C->new(year => 2003, day => undef )
> > # would give 2003-xx-01-T00:00:00?
> >
> > my $dtc2 = $dtc1->set( month => 12 );
> > my $christmas = $dtc2->set( day => 24 );
> ># Do these clone BTW or are $dtc1, $dtc2 and $christmas all refs
> ># to the same object (like DateTime does)?
> >
> > my $december = $christmas->set(day => undef);
> >
> > print $december->datetime;
> > # -12-xxTxx:xx:xx
> >
> > # See above question re cloning objects.
> > print $christmas->next( DateTime->now )->datetime;
> > # 2003-12-24Txx:xx:xx
> >
> > my $xmas_noon = $christmas->clone()->set( hour => 12 );
> >
> > print $christmas->contains( $xmas_noon );
> > # 1
> > --
> >
> > Regarding the cloning question, it is more like DateTime if they do
> > not get cloned autmomatically, but I am assuming your implementation
> > is based on your DT::Set which I think does clone automatically? I
> > would still vote for not cloning.
Re: RFC: DateTime::Complex
I like the idea (this is the partial date & time thing right?) but I am not too sure about the name... unless you start dealing with times with real and imaginary parts :-) (Not that I have any suggestions for a name yet). Regarding the interface would it be better to have: -- my $dtc1 = DateTime::Complex->new_undef(); # I assume that DT::C->new() assumes 0 like DT->new() # but that DT::C->new(year => 2003, day => undef ) # would give 2003-xx-01-T00:00:00? my $dtc2 = $dtc1->set( month => 12 ); my $christmas = $dtc2->set( day => 24 ); # Do these clone BTW or are $dtc1, $dtc2 and $christmas all refs # to the same object (like DateTime does)? my $december = $christmas->set(day => undef); print $december->datetime; # -12-xxTxx:xx:xx # See above question re cloning objects. print $christmas->next( DateTime->now )->datetime; # 2003-12-24Txx:xx:xx my $xmas_noon = $christmas->clone()->set( hour => 12 ); print $christmas->contains( $xmas_noon ); # 1 -- Regarding the cloning question, it is more like DateTime if they do not get cloned autmomatically, but I am assuming your implementation is based on your DT::Set which I think does clone automatically? I would still vote for not cloning. -ben On Fri, Jul 18, 2003 at 11:15:30AM -0300, Flavio S. Glock wrote: > RFC: DateTime::Complex > > use DateTime; > use DateTime::Complex; > use strict; > > my $dtc1 = DateTime::Complex->new_undef; > > my $dtc2 = $dtc1->define_month( 12 ); > my $christmas = $dtc2->define_day( 24 ); > > my $december = $christmas->undef_day; > > print $december->datetime; > # -12-xxTxx:xx:xx > > print $christmas->next( DateTime->now )->datetime; > # 2003-12-24Txx:xx:xx > > my $xmas_noon = $christmas->define_hour( 12 ); > > print $christmas->contains( $xmas_noon ); > # 1 > > [some too-weird examples removed] > > :) > - Flavio S. Glock
Re: Need help from Aussies for time zone stuff
Do they call the standard and summer times different things? The current DT::TZ stuff and POSIX::strftime and date on Linux and Solaris all say EST in January and July... I have also seen it given as EAST and EADT (actually I just checked www.worldtimezone.com and it gives AEST, AES, EAST and EST all as possible variations... bah!). Iain, which state do you live in, and what is the short TZ name in January and July? Also, how do you tell the times from Queensland apart from those in Victoria during DST? I wonder if Olsen has the wrong short names? The notes at the bottom indicate that is possible. -ben On Fri, Jul 18, 2003 at 02:12:51PM +1000, Rick Measham wrote: > At 2:09 PM +1000 18/7/03, Iain Truskett wrote: [...] > IIRC the entire East Coast used to be the same and called it 'Eastern > Standard Time' and 'Eastern Summer Time'. Of course, the states are > all different now, but still call it 'AEST' and 'AEDT'!
Re: UTC FAQ for DT
I like it! Barring any complaints I will happily put it up. (Maybe with a test case that exposes a leap second so that if the handling changes we will rememer to change the text). -ben On Thu, Jul 17, 2003 at 10:03:13AM -0700, Bruce Van Allen wrote: > Hi All: > > Here's a second revised FAQ covering DateTime's use of the UTC time scale. If this > is OK (Dave and Flavio?), Ben, could you add it to the DT FAQ? > > Some may have seen the news that debate has flared up regarding the continued use of > leap seconds. I don't know whether it will be resolved soon, so it seemed best to > simply acknowledge the issue, and hope we remember to update the FAQ if something > radically changes. > > This FAQ entry gets longer every revision, but it seems important for acceptance of > DT that we have a fairly rigorous explanation. > > ## FAQ entry: > > What time scale does DateTime follow? > What's up with UTC, GMT, TAI, and UT1? > > The DateTime modules are based on a time scale known as UTC (Coordinated Universal > Time), which was established internationally in 1972. > > UTC is widely used in scientific and technical contexts, and is increasingly > accepted as the standard time scale for civic and business uses. > > Related time scales include: > - GMT (Greenwich Mean Time), in which each twenty-four hour day has exactly 86,400 > uniform seconds by international convention (the "imperial clock"); > > - UT1 (Universal Time), in which day length varies, and is slowly changing, due to > irregularities in the earth's rotation detected by astronomical observations (the > "earth clock"); > > - TAI (Temps Atomique International), in which a day has 86,400 seconds whose length > is derived from a chosen atomic resonance at sea level (the "atomic clock"). > > UTC was developed to combine the stable atomic precision of TAI with the earth-sun > accuracy of UT1. > > TAI was originally synchronized with UT1 on 1958 January 1 (i.e., on that date, UT1 > - TAI = 0). To reconcile the divergence since then between TAI and UT1, UTC is > defined to differ from TAI by integer atomic seconds and to differ from UT1 by less > than .9 atomic seconds. > > To maintain this relationship, leap seconds are introduced as needed to the UTC time > scale, under the supervision of the International Earth Rotation and Reference > Systems Service (http://www.iers.org/iers";>IERS). > > The DateTime modules account for UTC leap seconds, providing full conformance with > UTC. > > NOTE: As of 2003, there was discussion about UTC's future use of leap seconds. In > the event of a change in the UTC definition, the most likely outcome is that the > DateTime modules will continue to follow UTC, and any leap seconds already > introduced will be preserved. > > ## End of FAQ entry # > > - Bruce > > __bruce__van_allen__santa_cruz__ca__
Re: DateTime parse(), parser()
Added to the FAQ.
Thanks!
-ben
On Thu, Jul 17, 2003 at 03:53:57PM +1000, Iain Truskett wrote:
> * Hill, Ronald ([EMAIL PROTECTED]) [15 Jul 2003 02:57]:
> > Hi John & Iain
>
> > > On Sunday, July 13, 2003, at 08:11 PM, Iain Truskett wrote:
> > > > Remember: part of the point of having the various format
> > > > modules is that you can pick'n'mix. You could conceivably
> > > > wrap a number of them in Builder to make your own parser
> > > > that recognizes the sorts of dates you come across. I mostly
>
> > I think an example of this type of thing needs to go into the
> > FAQ. Do you have an example of doing this?
>
> #!/usr/bin/perl -w
> use strict;
>
> package DateTime::Format::Fall;
> use DateTime::Format::HTTP;
> use DateTime::Format::Mail;
> use DateTime::Format::IBeat;
>
> use DateTime::Format::Builder (
> parsers => { parse_datetime => [
> sub { eval { DateTime::Format::HTTP->parse_datetime( $_[1] ) } },
> sub { eval { DateTime::Format::Mail->parse_datetime( $_[1] ) } },
> sub { eval { DateTime::Format::IBeat->parse_datetime( $_[1] ) } },
> ] });
>
> package main;
>
> for ( '@d19.07.03 @704', '20030719T155345', 'gibberish' )
> {
> print DateTime::Format::Fall->parse_datetime($_)->datetime, "\n";
> }
> __END__
>
> cheers,
> --
> Iain.
Re: Damn DST...
Sorry, I didn't mean to impugn DT::TZ::Alias, it is not an Alias problem. I am not sure how to resolve this, I certainly don't want to have to make DT::F::Simple accept a time zone mapping table as an argument (giving both the offsets and the names for things) since that duplicates the DT::TZ::Alias thing. Also I think this is a more general problem anyway. One possible answer is to say that 'Wed, 16 Jun 94 07:29:35 CST' is an invalid time since CST doesn't apply for that date (if you are using CST does that always mean that you will be honoring DST?). The ugliness here is I should return undef if the date is invalid, but I see no way to check that it occurred (our short names will not always match the parsed ones, e.g. the TZ GMT returns the short name UTC). I am currently ignoring the problem, so I parse the above string as if it were in CDT. Which certainly seems like a hack, but I am willing to live with it. However, I didn't realize that DT::TZ::Alias didn't allow you to alias a name to an offset. I think that is an important feature. (Although you probably should not be allowed to have an alias with a name that looks like an offset...). -ben On Wed, Jul 16, 2003 at 06:27:13PM -1000, Joshua Hoblitt wrote: > > Ok so in the test suite for Date::Parse is the format: > >Wed, 16 Jun 94 07:29:35 CST > > > > Fair enough, so I do: > > -- > > use DateTime::TimeZone::Alias > > CST => "America/Chicago"; > > > > ... > > -- > > > > Except that parsing the string gives: > >1994-06-16 07:29:35 CDT > > > > The problem is that TZ::Alias is happly causing CST to be treated as > > America/Chicago. But it isn't really America/Chicago, but rather > > -06:00, but then the returned date is in the wrong time zone. Ideally > > it would use the offset first, then set the time zone to > > America/Chicago which would cause the local time to change because of > > DST, but the absolute time would be correct. > > If I understand you correctly you want to cause a datetime that was expressed > without DST to be converted to DST. This seems a little bit screwy. Your either > going to have to mangle the time by hand or parse it as an offset and then convert > the TZ. > > The best DT::TZ::Alias could do would be to allow numeric only offsets to be > aliased. That would get you: > > use DateTime::TimeZone::Alias CST => "-0600"; > > This would be a fairly minor change to the module. Although your still going to > have to set the resulting object's TZ to "America/Chicago". > > -J > > --
Re: DateTime parse(), parser()
Well, I don't think that the simple is supposed to indicate simple to
parse (at the moment the parser is all but simple... but I am trying
to clean it up). I read it as "simple formats", i.e. common formats
that define the date and time in fairly straightforward ways (month names
and numbers for things are fine, "next week" "third thursday in the
next month with a blue moon" are not).
The other problem I see is that your regexp only covers English
speaking locales... I am currently using the DateTime::Locale date to
get locale sensitive information for parsing month and day names.
(Although AM/PM and BC/AD are a bit of a problem, I may need to add
extra information somewhere).
-ben
On Wed, Jul 16, 2003 at 11:30:33AM -0400, John Siracusa wrote:
> On 7/16/03 11:21 AM, Ben Bennett wrote:
> > On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
> > [snip]
> >> IMO. Also, I don't think DT::Infinite is in the same boat, because
> >> that is a legitimate date (that DT::F::Simple must parse, BTW:
> >> /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error!
> >
> > Is infinity really a simple date? I think no. Anyone else want to
> > weigh in?
>
> Either way, I'll weigh in again! :) Of course it's "simple" because, in the
> context of DT::F::Simple, "simple" means "simple to parse." And this is
> pretty darned simple, IMO:
>
> if(/^([-+])?inf(?:inity)?$/i)
> {
> if($1 eq '-')
> {
> return DateTime::Infinite::Past->new;
> }
>
> return DateTime::Infinite::Future->new;
> }
>
> -John
Re: DateTime parse(), parser()
On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote: [snip] > IMO. Also, I don't think DT::Infinite is in the same boat, because > that is a legitimate date (that DT::F::Simple must parse, BTW: > /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error! Is infinity really a simple date? I think no. Anyone else want to weigh in? -ben
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Wed, Jul 16, 2003 at 12:05:00PM +0200, Claus Färber wrote: > Iain Truskett <[EMAIL PROTECTED]> schrieb/wrote: > > * Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]: > > My quibble; the name. I'm not a huge fan of ::Simple and ::Lite. > > Unfortunately, I can't think of a nice alternate for it. > > Maybe DateTime::Format::Universal? Urm... I am a little reluctant to claim that I parse the universe of dates... > Not all languages use suffixes when writing numbers. In German, for > example, you'd just write "14. Juli". (Actually, it's spoken > "vierzehn*ter* Juli", but one does not write "14ter Juli"; in spoken > language, the suffix is also used for the month as in "vierzehnter > siebter" or "14ter 7ter"). Great! Someone who can tell me real German usage! In the example above, is the . after 14 optional? I assume so... Can you clarify what AM/PM and BC/AD forms would be expected? Thank you! -ben
Re: Changable locale data...
Speed? -ben On Tue, Jul 15, 2003 at 09:42:02PM -1000, Joshua Hoblitt wrote: > On Tue, 15 Jul 2003, Dave Rolsky wrote: > > > On Tue, 15 Jul 2003, Ben Bennett wrote: > > > > > DateTime::Locale objects return references to internal data. So if a > > > caller changes things through the ref subsequent calls will see the > > > bogus data. > > > > > > I am not sure if this is a problem or not, but we should at least > > > document that the caller _must_not_ change things through the ref. > > > > The locale objects really aren't intended to be used by end-users. But > > yes, this should probably be documented. > > Is there a good reason to return a direct reference? > > -J > > --
Re: DateTime::Format::Pg problem
fractional_seconds is deprecated... nanoseconds have to be specified separately. I dunno if Pg has been updated to use the new interface yet. -ben On Tue, Jul 15, 2003 at 12:30:39PM -0700, Alex Boster wrote: > DateTime::Format::Pg dies when I parse an ISO date. Can anyone point me > in the right direction? I looked at the module's code, and I can't find > the problem. The regex should match and fractional_seconds is in fact > on the params list. > > [EMAIL PROTECTED] aboster]$ cat dt_test.pl > #!/usr/local/bin/perl -w > > use DateTime; > use DateTime::Format::Pg; > use strict; > > my $str = '2003-07-14 09:37:33-07'; > my $d = DateTime::Format::Pg->parse_datetime($str); > print Dumper(\$d); > > [EMAIL PROTECTED] aboster]$ ./dt_test.pl > The following parameter was passed in the call to DateTime::new but was > not listed in the validation options: fractional_second > at > /usr/local/lib/perl5/site_perl/5.8.0/DateTime/Format/Builder/Parser/Regex.pm line 135 > [EMAIL PROTECTED] aboster]$ > > Since there are warnings in the docs about setting a timezone, I have > also tried instantiating the a DateTime::Format::Pg object with the > server_tz set and then calling the parse_timestamptz function. The > behavior is the same. (No surprise as this is the first parser tried by > the more general function above.) > > This is DateTime::Format::Pg version 0.04. > > Thanks in advance, > Alex > > PS: Here's hoping I haven't missed something really obvious and am > making a public spectacle of it...
Re: Ambiguous years (what does 03 mean?)
I think all that page is propsing is using the date of the file
creation rather than the current date. Both windows 'move'.
I suppose I can consider adding a year parameter to the thing (at some
point in the future, first I want to get the basic functionality
working without too many feeping creatures). Also I will consider a
pedantic flag that will enable some warnings about ambiguous dates (or
perhaps a flag to prevent use of ambiguous dates). But that will all
be later...
-ben
On Tue, Jul 15, 2003 at 02:42:02PM -0400, John Peacock wrote:
> Dave Rolsky wrote:
>
> >I think the standard is something along the lines of:
> >
> > if ($year + 50 < ($current_year - 2000)) { $year += 1900 } else { $year
> > += 2000 }
> >
>
> Except that this will probably be wrong when used to convert birthdates of
> retirees (actual project I had to deal with, BTW). See:
>
> http://www.dmi.uiuc.edu/y2k/window.htm
>
> for a way to handle moving windows.
>
> The two digit year format is so pernicious that it demands a warning in
> pretty much all cases, and an error in any situation where the data is
> important.
>
> John
>
> --
> John Peacock
> Director of Information Research and Technology
> Rowman & Littlefield Publishing Group
> 4501 Forbes Boulevard
> Suite H
> Lanham, MD 20706
> 301-459-3366 x.5010
> fax 301-429-5748
Re: ICU data and date formats...
On Tue, Jul 15, 2003 at 01:22:36PM -0500, Dave Rolsky wrote:
> On Tue, 15 Jul 2003, Ben Bennett wrote:
[...]
>
> As long as the fact that everything defaults to 'root' (which is basically
> 'en_US') is well-documented, I don't see a problem.
>
> What you're proposing would mean that for many locales, there would be
> _no_ date formats, which will just cause random breakage when people try
> to use something like $dt->strftime('%c'). Having this randomly throw
> exceptions is not a good thing.
Oh damn. My instrumented version of generate_from_icu was changing
the behvior so I was ending up with an empty %time_formats structure
that I thought would cause problems.
So it looks like your code is doing part A already and you are of
course correct that everything should inherit from root to make sure
that the strftime behavior is reasonable.
Sorry all,
-ben
Another wrinkle...
It turns out that a handful of locales (e.g. af_ZA, en_ZA, fa, hr, hu, ja ...) have dates with the form y/m/d. So it looks like the value for the date component order (and the optional parameter to DT::F::Simple) should be a string that can take the 3 values: 'ymd' 'dmy' 'mdy' Does this make sense? -ben
Changable locale data...
DateTime::Locale objects return references to internal data. So if a caller changes things through the ref subsequent calls will see the bogus data. I am not sure if this is a problem or not, but we should at least document that the caller _must_not_ change things through the ref. -ben
ICU data and date formats...
A bunch of the locales (e.g. ar_SY) have no date formats, but have other stuff defined so they pass the has_data() check. In this case I think they should inherit from their parent (ar). However, there are some base languages (e.g. az) which have no date format information defined but their sole child (e.g. az_AZ) has them. The problem in this case is that the dates defined by az_AZ are of the form dd.MM., but root is M/d/yy so simply inheriting the root one is probably incorrect. So I propose the following: A) If a locale (specified by language and territory) has no date format then it should inherit that of the language B) If a language has no date format then no date format can be determined. For the DT::F::Simple stuff that will mean that there is no default month and day ordering, so it will throw an error unless one is provided separately. Does this make sense? I think A can be implemented by simply changing the subclass not to generate a date_formats sub since it ISA the parent class. I have not looked to see if there is a similar issue with month and day names not being defined, but I assume that there is. I assume that a similar fix will be sufficient if there is a problem. Thoughts? -ben
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, Jul 15, 2003 at 11:40:16AM -0500, Dave Rolsky wrote: > On Tue, 15 Jul 2003, Ben Bennett wrote: > > > Actually, I was thinking that this would be done when generating the > locale modules. It shouldn't be _too_ hard, I think. Sorry, that was where I was intending to fiddle with, I just wanted to make sure it was possible to do it for all of the locales (or at least a reasonable number of them). > Again, see above. You're welcome to tweak the generator code in the > DateTime::Locale CVS. Cool. -ben
Ambiguous years (what does 03 mean?)
Given the date 02/11/03 in the locale en_US (so you can assume m/d/y), what year is that in? As a human I say that is 2003. What should the rule be? Does the following sound reasonable: 1) Work out the current decade (now 00) 2) Any date in the current and next decade (00, 10) are assumed to be in the future 3) All other dates are assumed to be in the past So, 03 = 2003 14 = 2014 24 = 1924 76 = 1976 This seems dodgy to me. Does anyone have a better idea (or know of a standard? Or how other programs handle it?) -ben
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Mon, Jul 14, 2003 at 11:39:37PM -0500, Dave Rolsky wrote: > On Mon, 14 Jul 2003, Ben Bennett wrote: > > > Which leads to my problem, there appears to be no simple way to get > > the date order to differentiate m/d/y from d/m/y. I can look at the > > time formats and try to work it out, but that seems a bit dodgy if you > > ever change the parser, plus I assume that I am not the only person > > who will want to know that. So could we break it out as an explicit > > method? > > We'd have to look at the _actual_ format strings to do this, but it's > certainly possible. Ok, I will play around with this and see if all of the locales have understandable short forms. > > Also the start of week infomation (and the weekend start and end) seem > > pretty useful for the financial stuff. Would it be reasonable to add > > them to the Locale objects? > > Probably. Cool, I may add that in the future if needed. -ben
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, Jul 15, 2003 at 12:14:00AM -0400, John Siracusa wrote:
> On 7/14/03 11:10 PM, Ben Bennett wrote:
[...]
> Sweet, someone took the bai--...er, "picked up the baton" ;)
Well I have been playing around with the idea for a while, but when
the locale stuff got in I decided it was time to stop fiddling and get
something useful together.
> I'm sure you're already doing this, but just in case, make sure to allow for
> single-digit numbers where there is no ambiguity. This is essential for
> handling "user-created" input. Examples:
>
> 9/3/2002 (e.g. don't require 09/03/2002)
> 1:02 (e.g. don't require 01:02)
Yes.
> and maybe even:
>
> 200210131:02
No! Egads :-) Actually I wasn't accepting the form 200210130102
either (I will accept 20021013T0102). Should I?
> but that may make some people break out in hives, so whatever :)
Scratch, scratch...
> Also,
> don't forget about the optional "." in "a.m." and "p.m." I'm not quite sure
> how that'd get localized, but the point is that the localized am/pm thingies
> must be regexes, not constant strings (or, okay, a regex constructed out of
> a list of constant strings, if you want :)
Yeah, I was trying to work that out. It appears not to be in the raw
locale data, so I was considering just accepting the am/pm stuff with
optional inserted periods, even for other locales. I still have to
survey all locales to see if that is even reasonable. The other
choice would be to special case BC and AD to allow the dotted form,
but that seems a bit restrictive.
> > Which leads to my problem, there appears to be no simple way to get
> > the date order to differentiate m/d/y from d/m/y.
>
> Don't. Make it a setting. I've been trying to think of what to name this
> setting, but have no good ideas. Here are some bad ones instead:
It would be a setting... locale.
> DT::F::Simple->use_mmdd(1);
> DT::F::Simple->use_ddmm(1);
>
> DT::F::Simple->mode('us');
> DT::F::Simple->mode('euro');
>
> DT::F::Simple->euro_mode(1);
> DT::F::Simple->us_mode(1);
>
> Gah, that's horrible :) Someone out there must have some sort of
> pre-existing vocabulary to describe the date format differences. Is it just
> regional, or are there ISO numbers to reference or what?
I can add an optional additional parameter dmy_mode (defaults to your
locale if undef) but I really think inferring it from the locale is
fine.
Speaking of which, what interface do people want?
my $us_parser = DateTime::Format::Simple->new(locale => "en_US");
my $dt = $us_parser->parse_datetime("2/11/74");
Or:
my $dt = DateTime::Format::Simple->parse_datetime(string => "2/11/74",
locale => "en_US");
Note that it will always be legal to call:
my $dt = DateTime::Format::Simple->parse_datetime("2/11/74");
And some locale will be assumed (probably en_US).
Another choice would be to allow both forms (which I may do to allow
user flexilbility).
-ben
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, Jul 15, 2003 at 01:56:53PM +1000, Iain Truskett wrote:
> * Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]:
[...]
>
> My quibble; the name. I'm not a huge fan of ::Simple and ::Lite.
> Unfortunately, I can't think of a nice alternate for it.
Ok. I will think about that (suggestions welcomed).
> Sounds good. Ignoring unknown day names?
I think so. I haven't decided yet.
> > Ommissions from Date::Parse:
> > - July 14th will not be parsed (I don't have localized info on the
> >numeric suffixes)
>
> How about you just assume /\d{1,2}\w+/?
Perhaps, I will play with it when the rest is finished. Input from
people who speak other languages would be appreciated. I think that
would be okay in French, I am a bit concerned about how it behaves
with non-Latin languages.
> > This will use the DT::F::Locales to get the localized forms of the
> > days and months.
>
> What happens in the event of input being in an unknown locale? As in "we
> don't know what locale this is in" rather than "we don't have locale
> data for xy_XX".
Erm... maybe later I will make something that can deal with ambiguous
locales. That seems like a non-Simple.pm task (I realize that it
isn't that hard to do, but may be slow).
> Not really. The best one can do is have it so dates that can only be one
> type and not the other are done correctly. Ambiguity is part of the
> reason ISO8601 and W3CDTF have their order specified and why rfc(2)822
> uses the month _name_.
If you have the locale then I think you should be able to assume
ordering.
> If "Simple" is to be simple, I'm not sure it can really handle such
> things. The idea of "Simple" modules is to have as little of an
> interface as possible. Inner complexity and outer simplicity.
See above.
-ben
Re: The arguement for time-only.
I vote that you assume the next valid instance of the time (e.g. if they say 4 o'clock and it is 11 PM now, assume 4AM of the following day). I believe this is what Date::Manip does and it seems to be reasonable most of the time. As another possibility (which is what I did with my obsolete version of the ISO8601 parser) is to optionally take an arbitrary DT object to use as the base and fall back to today otherwise. I also returned additional items in array context, the first was the DT object and the additional items described what was parsed so if the person cared about time only in some cases they could tell them apart from the fully specified items. Additionally I allowed the user to tell the parser what formats were valid. I don't know if that is applicable in this parser though. -ben On Mon, Jul 14, 2003 at 08:19:07AM +1000, Rick Measham wrote: > I'm working with DateTime::Format::Natural and I really need a time-only > object. In fact I need an object that lets me chose what I want to give > it. > > For example: "It was 12 o'clock" - we know from this the hour, minute > and second but have no idea of the day, month or year. > > Also: "It was June 25" - no year, no time, but a valid date > none-the-less. Sure there's some date math we can't do with it but we > can still format it. > > What should I do with these? Currently I'm returning -01-01 00:00:00 > and subing in the parts I do know, but this is just wrong! > > Cheers! > Rick
Re: DT::E::NameDay in CVS
Oops, my bad. I will mail the request. -ben On Sun, Jul 06, 2003 at 07:24:42PM -0500, Dave Rolsky wrote: > Why is the directory called DateTime-Event-NameDay-0.02? Ben, can you ask > SF to change this, please? > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: DateTime::Format::ISO8601 namepsace
On Sat, Jul 05, 2003 at 06:56:32PM -1000, Joshua Hoblitt wrote: > I want to preserve the revision history of my tree so the move to SF won't be until > next week. Ok. > What really needs to be done is a lot more tests. I'm considering a framework for > building tests. Ok, I can try to port over my framework when your code is checked in, although it relies on being able to pass in a base date and be able to select the return classes so I am not sure how easy it is to do. > > I have some additional functionality that I think is critical: > > 1) The ability to say which pieces of the ISO spec are applicable > > (otherwise you can not tell the formats with leading -s apart from > > the ones with expanded years). Also you need to be able to > > specify the number of additional years > > The simple solution is parse_time - a better one is coming. What is your proposed API? From the discussion on the DT list Dave preferred extra arguments to parse_datetime which is what I ended up implementing. > > 2) Return information about the matching format so that you can tell > > which information is ommitted in the reduced formats. (e.g. I > > want to be able to tell the year 2003 apart from Jan 1 2003. > > I agree but we don't have attributes for DT yet. Yes, but you don't need them. In the interface discussion Dave said using wantarray() and returning extra fields was fine. > > Then some other information that would be nice: > > 3) Return the parts of the string that matched (in addition to 2 > > above, this makes handlind reduced formats more pleasant, rather > > than having to infer the week number from a returned DateTime). > > Return how? My module had the return signature ($datetime_object, $format_info, $parsed_parts) = parse_datetime( ... ) > > 4) The ability to specify an arbitrary base date for the implied > > computations and times > > I agree with this. But what is there now works well... I disagree. When I am dealing with a time I need to be able to say what date is implied. > > I also think you will need 3 to support durations that have the form > > of a date (especially since they may not be valid dates if parsed by > > DateTime, e.g. P0002-02-30, for a duration of 2 years, 2 months and 30 > > days). > > Invalid dates should raise an exception. I'm not sure what to do about the longer > then 1 year problem. My thinking is a DT::Duration::Set with multiple durations but > the whole thing is fuzzy right now. No, I think you misunderstand. They are not invalid dates because they are not dates. The duration format has 2 valid syntaxes, one is the explicit P2Y2M30DT4H5M6S syntax, the other specifies them as if they were dates, so the above period can also be P00020230T040506 which is a valid duration, but an invalid date if you use your date parser to parse it rather than duplicate the formats. > > c) Your fractional_hour does not compute seconds and nanoseconds > > (i.e. T10.412342 gives precisely 10:24:00) > > Hmm... I'm not sure that this is wrong. The spec is kinda vague. Fair enough. > > d) Your parse_time only parses the ambiguous time formats, some time > > formats are only in parse_datetime > > This is the same as your point #1. I don't think so. All I am saying here is that some time formats are only parsable with parse_datetime and others with parse_time. I would have expected all time formats to be parseable with parse time and not with parse_datetime (unless perhaps they had a leading T). > > Other issues (that I didn't solve either): > > i) You assume that a minute is 60 seconds in the fractional code > > ii) For fractional durations, how do you represent .3 of a month? > > (The best answer I could come up with was to use the base date or > > today to get the number of days in a month). > > > Sure, but how much further is it worth bending DT::F::Builder to > > handle this finicky standard? > > A lot. :) This isn't the only weird standard. No, my point is how far should it bend specifically for this standard? > > > As I've said from the beginning I think your parser is very interesting and I > > > don't want to see you abandon it. Perhaps it should be extracted from the > > > ISO8601 specific stuff and rolled into a stand alone module for specifying > > > date/time formats. Maybe DateTime::Format::Grammar? > > > > I honestly don't think it is usefull outside of the context of > > ISO8601, it has a lot of the odd ISO stuff baked into it and if you > > were to do a generic Grammar then DT::F::Builder is a simpler base > > (unless you need lots of odd semantics in which case it is probably > > better to roll your own). > > I don't think you could write a Date::Manip replacement in DT::F::Builder yet. Your > parser would be pretty good for this. I agree with the first point, but I am not sure about the second. -ben
Re: DateTime::Format::ISO8601 namepsace
On Fri, Jul 04, 2003 at 09:11:22AM -1000, Joshua Hoblitt wrote: > I'm planning on moving my tree to SF CVS as soon as I return from OSCON. Then we > can merge as much as we can from your tree into mine. I assume you have a personal CVS repository? Otherwise you can just cvs add it over... > A new version was sent to CPAN last night. A road-map was sent to the list along > with the release. Basically the next release will be bug fixes and more tests - > hopefully a thousand or more new tests. Then the ISO section 5.5 stuff can be > started on. I'm planning on working with Iain and Flavio for any changes needed to > DT::F::Builder or DT::Duration::Set (when it's written). Sorry, I skipped over that message. I dug it up and read it. I have some additional functionality that I think is critical: 1) The ability to say which pieces of the ISO spec are applicable (otherwise you can not tell the formats with leading -s apart from the ones with expanded years). Also you need to be able to specify the number of additional years 2) Return information about the matching format so that you can tell which information is ommitted in the reduced formats. (e.g. I want to be able to tell the year 2003 apart from Jan 1 2003. Then some other information that would be nice: 3) Return the parts of the string that matched (in addition to 2 above, this makes handlind reduced formats more pleasant, rather than having to infer the week number from a returned DateTime). 4) The ability to specify an arbitrary base date for the implied computations and times I also think you will need 3 to support durations that have the form of a date (especially since they may not be valid dates if parsed by DateTime, e.g. P0002-02-30, for a duration of 2 years, 2 months and 30 days). Bugs that I have noticed: a) The parser allows partial extended form on the times, so it takes 12:3000... b) It does not allow all combined date and time formats that are legal (any non-truncated date and any non-reduced time combination is legal), also the whole expression must be either entirely in basic or expanded form (not mixed) c) Your fractional_hour does not compute seconds and nanoseconds (i.e. T10.412342 gives precisely 10:24:00) d) Your parse_time only parses the ambiguous time formats, some time formats are only in parse_datetime Other issues (that I didn't solve either): i) You assume that a minute is 60 seconds in the fractional code ii) For fractional durations, how do you represent .3 of a month? (The best answer I could come up with was to use the base date or today to get the number of days in a month). > By collaborating with Iain while working on my ISO parser many very useful features > have been incorporated into DT::F::Builder. I'd like to continue along this path as > it has potential benefits for other authors. Of course your help is welcomed. Sure, but how much further is it worth bending DT::F::Builder to handle this finicky standard? > As I've said from the beginning I think your parser is very interesting and I don't > want to see you abandon it. Perhaps it should be extracted from the ISO8601 > specific stuff and rolled into a stand alone module for specifying date/time > formats. Maybe DateTime::Format::Grammar? I honestly don't think it is usefull outside of the context of ISO8601, it has a lot of the odd ISO stuff baked into it and if you were to do a generic Grammar then DT::F::Builder is a simpler base (unless you need lots of odd semantics in which case it is probably better to roll your own). -ben
Re: DT::Duration::Set
Can you expand on this please? -ben On Sat, Jul 05, 2003 at 04:31:12AM -0400, Matt Sisk wrote: > Dave Rolsky <[EMAIL PROTECTED]>: > > Can you and/or Joshua explain what this would be used for? > > > > Unbounded clocks? > > Matt
Re: DateTime::Format::ISO8601 namepsace
So is there any conclusion here? Should I commit my module or will Joshua commit his? -ben
Re: DateTime::Set::ICal
I assume that this only works for things created by ICal... Or can I make a set using DT::E::Recurrence and expect to be able to serialize it out using DT::F::ICal? Cool stuff though. -ben On Fri, Jul 04, 2003 at 02:00:34AM +, [EMAIL PROTECTED] wrote: > Ok, I've got DateTime::Set::ICal implemented under > DT:E:Recurrence. It's an 'internal use' class for > recurrences that can be represented using ICal > statements. > > DT::Format::ICal can now format pretty complex sets > as ICal statements: > > example from t/04recurrence.t: > .. > my $exclude = $union2->union( > $ical->parse_datetime( '19980303T030303' ) >)->complement( > $ical->parse_datetime( '19980404T040404' ) >); > @str = $ical->format_recurrence( $exclude ); > > # output: > > RRULE:FREQ=YEARLY;BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA > RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU,MO,TU,WE,TH,FR,SA > RDATE:19980303T030303 > EXDATE:19980404T040404 > > format_recurrence() dies if it can't find a proper > ICal representation for a set. > > - Flavio S. Glock >
Re: DateTime::Format::ISO8601 namepsace
On Thu, Jul 03, 2003 at 12:01:33PM -1000, Joshua Hoblitt wrote: > > We could use a DT::Duration::Set module for things > > like "once a week for 3 weeks" > > That would be ideal. Especially if (given a start or end date) you can turn it into a DateTime::SpanSet > > How is that different from an ICal recurrence? I am not sure. I really haven't looked at the ICal stuff. > > Do we need a DT::Event::ISO8601 ? > > I've been thinking about this for a few days. I don't think that DT::Event::ISO8601 > would be useful on it's own. DT::F::ISO8601 should just return a recurrence. I agree (assuming you mean a DT::SpanSet). The ISO8601 format is so simple that I doubt you would want to create Sets that way (DT::E::Recurrence is much more useful). By the way, I have no idea why the recurrence syntax is at all useful since there is no way to inducate spacing between the items. I suppose if the applications wanted they could ignore the length of the recurrence and treat the starts as point events (or associate lengths with them some other way). But it is in the spec so... -ben
Re: DateTime::Format::ISO8601 namepsace
Sorry to reply to myself, but the new version of this thing is available at: http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz I think this is in roughly releaseable form. I still have some TODO items in the code (actually marked with XXX) but they are small items that clean things up. The POD is rough but reasonable. The test suite is decent (it is all of the strings from the ISO appendix and a few others I threw in). I hope to add more, as well as adding negative tests (i.e. strings I don't expect to be able to parse, or ones that don't match the given type and class). Remaining future development: - Add recurrence parsing (only issue is how to handle recurrences of the form "once a week for 3 weeks" that has no date specified) - Add formatting of objects into ISO8601 strings (hopefully I can use the recurrence stuff Flavio has been working on to write out a recurrence). Please advise. -ben
Re: DateTime::Format::ISO8601 namepsace
Ok, the new interface on mine is complete. The only thing missing is POD and I will do that now. The major problem with merging mine and Joshua's is that they take totally different tacks for the implementation. -ben On Thu, Jul 03, 2003 at 08:56:39AM -1000, Joshua Hoblitt wrote: > > Joshua, why don't you check yours into CVS as DT::F::ISO8601, release it, > > and then you and Ben can merge in all the extra functionality from Ben's > > module. > > I wanted to dump it into CVS long ago but the namespace issue never cleared up. > > I'll try to get my laptop online tonight to make a CPAN release. As I'm on the road > and without regular net access on my laptop I might wait a little bit before asking > SF to insert my tree, so I can keep working (this particular CVS limitation really > drives me nuts). > > > My only "rule" for this is that there should only be one DT::F::ISO8601 > > module, and that _eventually_, it should handle the complete spec. > > Not a problem. > > -J > > --
Re: DateTime::Format::ISO8601 interface questions...
Cool, that is the method that I have started on. -ben On Thu, Jul 03, 2003 at 01:03:09PM -0500, Dave Rolsky wrote: > On Thu, 3 Jul 2003, Ben Bennett wrote: > > > There is a lot to work out, but once the interface is clear it should > > be very quick to implement. > > > > Do you have any suggestions for what the interface should be or should > > I just take a whack at it and see what people think? > > Probably for unambiguous cases we should just allow: > > $iso->parse_datetime($string) > > For more complex cases we can do: > > $iso->parse_datetime( datetime => $string, >... # extra params > ) > > This probably works better than many methods, in this case, because there > seem to be many combinations of different parameters (format, base object, > timezone, etc.) so trying to method-ize those would generate a ridiculous > number of methods. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: DateTime::Format::ISO8601 interface questions...
There is a lot to work out, but once the interface is clear it should
be very quick to implement.
Do you have any suggestions for what the interface should be or should
I just take a whack at it and see what people think?
-ben
On Thu, Jul 03, 2003 at 11:43:03AM -0500, Dave Rolsky wrote:
> On Thu, 3 Jul 2003, Ben Bennett wrote:
>
> >
> > I am not sure what interface to use for the advanced features of the
> > ISO8601 parser I wrote. Right now I use a quick hack to make it work
> > so I can test the parser. It should be easy for me to change the
> > interface to something sane, I just don't know what that should be.
> >
> > The basic usage should be:
> > --
> > my $iso = DateTime::Format::ISO8601
> > my $dt = $iso->parse_datetime("20030211");
> > --
> >
> > However, I want to be able to accept the following optional arguments:
> > - The classes of formats to parse (Dates, Times, DateTimes,
> >Durations, Recurrences)
> > - The base DateTime object to use when things are implied (e.g. the
> >date component when dealing with times, or any Truncated format,
> >and some recurrences) If not supplied this defaults to now().
> > - The types to allow (each group is independent so you can have a
> >Basic, Reduded, Week, Fractional, Expanded DateTime format):
> >
> >- Basic (no separators)
> >- Extended (with separators)
> >
> >- Complete (fully specified class, no pieces missing)
> >- Reduced precision (missing lower order items, e.g. year only)
> >
> >- Truncated (whether higher order items are implied, e.g. ---12
> > specifies 12th day of current month and year)
> >
> >- Fractional (Time components may be represented as a fraction)
> >
> >- Expanded (The year may have additional digits and may be negative)
> >
> >- Ordinal (Days are expressed as Nth day of a year)
> >- Week (Days are expressed as Nth day of Mth ISO week)
> >
> >- Timezone (Whether a timezone is allowed)
>
> Ok, so basically there's a lot left to work out for your parser.
>
> In that case, I think the ideal thing to do would be to release Joshua's
> parser now as DT::F::ISO8601, and then to continue work on yours, making
> it backwards compatible with Joshua's.
>
> Or in other words, please merge the damn things! ;)
>
>
> -dave
>
> /*===
> House Absolute Consulting
> www.houseabsolute.com
> ===*/
DateTime::Format::ISO8601 interface questions...
I am not sure what interface to use for the advanced features of the
ISO8601 parser I wrote. Right now I use a quick hack to make it work
so I can test the parser. It should be easy for me to change the
interface to something sane, I just don't know what that should be.
The basic usage should be:
--
my $iso = DateTime::Format::ISO8601
my $dt = $iso->parse_datetime("20030211");
--
However, I want to be able to accept the following optional arguments:
- The classes of formats to parse (Dates, Times, DateTimes,
Durations, Recurrences)
- The base DateTime object to use when things are implied (e.g. the
date component when dealing with times, or any Truncated format,
and some recurrences) If not supplied this defaults to now().
- The types to allow (each group is independent so you can have a
Basic, Reduded, Week, Fractional, Expanded DateTime format):
- Basic (no separators)
- Extended (with separators)
- Complete (fully specified class, no pieces missing)
- Reduced precision (missing lower order items, e.g. year only)
- Truncated (whether higher order items are implied, e.g. ---12
specifies 12th day of current month and year)
- Fractional (Time components may be represented as a fraction)
- Expanded (The year may have additional digits and may be negative)
- Ordinal (Days are expressed as Nth day of a year)
- Week (Days are expressed as Nth day of Mth ISO week)
- Timezone (Whether a timezone is allowed)
I would also like to be able to return additional information about
the format and the parsed components. This would allow some
introspection when dealing with an unknown format. For instance if I
know I may get a reduced format I may want to handle it differently in
my application, but I need to know if I am dealing with a year, decade
or century.
I could handle this by detecting how many items are passed as
arguments to parse_datetime() and handling it as a hash if I get more
than 1. Similarly I can return different items if I am called in
array context... However, if you call parse_datetime() and get a
DateTime::Duration object back that seems wrong.
I think the thing to do is make the parse_datetime() be a wrapper for
a sub with named parameters that restricts things to DateTime objects
only. If you want the full power of the parser you need to call
parse_iso8601() or something. Only parse_is08601 will support
returning multiple items using wantarray to detect the calling
context.
Or I perhaps you have to make an object and call parse_datetime()
through the object if you want to do anything complex.
I am leaving the formatting side out of the intial discussion, but it
has similar problems, for instance it needs to be able to take similar
format parameters to work out what kind of string to produce.
Does anyone have any suggestions. I looked at the existing DT::F::
modules but they don't appear to have any similar interface problems.
Any suggestions would be appreciated.
Thanks,
-ben
Re: DateTime::Format::ISO8601 namepsace
Well mine currently does that and parses durations... Joshuas can probably be changed to do so, but I am not motivated to do the work. -ben On Thu, Jul 03, 2003 at 10:13:04AM -0500, Dave Rolsky wrote: > On Thu, 3 Jul 2003, Ben Bennett wrote: > > > I am okay with this decision. However Joshua's parser does not allow > > selection of which pieces of the spec are applicable so you can have > > ambiguous cases. > > > > Anyway, I will rename my parser to > > DateTime::Format::ISO8601::Complete and release it. > > Ugh, no. Please, let's just have one parser. Can't we have one that, by > default, parses all the common, unambiguous cases, and also allows you to > specify additional info so that ambiguous formats are parsed as well? > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: DateTime::Format::ISO8601 namepsace
I am okay with this decision. However Joshua's parser does not allow selection of which pieces of the spec are applicable so you can have ambiguous cases. Anyway, I will rename my parser to DateTime::Format::ISO8601::Complete and release it. -ben On Thu, Jul 03, 2003 at 06:39:58PM +1000, Iain Truskett wrote: > * Joshua Hoblitt [03 Jul 2003 18:09]: > > I've resolved the last known bug my ISO8601 parser and I > > believe it is ready for CPAN. Unless I hear an objection > > I'm going to use the DateTime::Format::ISO8601 namespace. > > +1 > > Please do. > > > I'm not claiming that this is the right namespace to use > > but the indecision needs to be settled. If this turns out > > to be the wrong choice things can always be renamed later. > > Do you parse ISO8601 dates? If so, you're there. > Any differences can be later integrated =) > > > cheers, > -- > Iain.
Re: ANNOUCE: DateTime::Format::DateManip
My module is a superset of Joshua's... however, mine still needs the interface to be polished (I plan on adding a way to select which optional pieces of ISO8601 are legal). Mine may also be slightly slower (but I don't think there is much in it). -ben On Tue, Jul 01, 2003 at 06:05:59PM -0500, Dave Rolsky wrote: > On Tue, 1 Jul 2003, Joshua Hoblitt wrote: > > > Agreed. I think it should boil down to recurrences and durations.. If > > most people need that functionality then lets call your module > > DT::F::ISO8601 and I'll use ISO8601::Simple. If they don't then I'll > > take ISO8601 and you can use ISO8601::Complex. > > Is there any reason it can't all go in one module? I think that'd be much > easier for end users. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: ANNOUCE: DateTime::Format::DateManip
On Tue, Jul 01, 2003 at 07:36:48AM -0700, Hill, Ronald wrote: > Yes, and so will Date::Calc (that is what I use) But I wanted to use only > one > Date module. It makes no sense to use say Date::Calc with DateTime. I know you provided a code snippet below, but in general when using Date::Calc do you use GMT or Local time when doing the operations? If you mix the two, how do you keep track of which is which? Do you use Date::Calc::Object? I am trying to work out what the interface should be for a possible DateTime::Format::DateCalc converter. I think it is too complicated to use the typical parse_datetime() style (because you need to tell the sub whether it is in GMT or local time). Also it would be nice to have a sub that could take the date and time parts and put them together into a DT and vice versa. Anyway, any suggestions would be appreciated. Thanks, -ben
Re: ANNOUCE: DateTime::Format::DateManip
On Tue, Jul 01, 2003 at 09:04:14AM -1000, Joshua Hoblitt wrote: > Looks good Ben. The timezone stuff must have been fun. :) Fun in which sense of the word :-) > I ported a small piece of code (in production though) from Date::Manip to DT not > long ago. I've been meaning to post the diffs and the benchmarks to the list. I'll > do it as soon as I'm back on a fast connection. Cool. > > Sometime I want to finish writing DateTime::Format::Complex that will > > grok complex "English" (although I want it to be localizable) date > > strings. But that is still under consideration. > > Has DateTime::Format::ISO8601::(?:Complex) grown into this or is it a different > module? No DT::F::ISO8601 (::?) is still a separate beast (which may get called by DT::F::Complex). ISO8601 parsing is pretty much done except for recurrences... I have some questions how to translate a recurrence that has 5 instances 20 minutes apart but does not give a start or end time. I may just do as I do elsewhere and use an optional user provided time (and fall back to now()). We should get this name thing resolved so we can get both modules committed and up on CPAN. I don't care either way. -ben
ANNOUCE: DateTime::Format::DateManip
I needed to convert between Date::Manip and DateTime so I wrote a module to convert the date and duration formats (recurrences may follow if there is demand, there are some nasty wrinkles though). Get it from http://www.limey.net/~fiji/perl/ If people see no major problems with this module I will add it to CVS and CPAN. I also want to update the FAQ with a section on how to convert between different timezone modules, since most of the other modules use epochs that is easy to handle. I wanted to write one to convert Date::Calc::Object as well, but timezones really get ugly there. Since the TZ info is not kept with the object the user would have to tell us whether it was in local or GMT time when converting in both directions. I am still thinking about how to handle the interface in a sane manner. -ben
Re: DateTime::Duration nits...
On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky wrote:
> > 2) Having a way to construct this directly would be nice being able
> > to make a duration that you can not directly construct seems odd.
>
> Well, maybe. Right now the constructor is really simple, which is good.
> More functionality is nice, but so is simplicity.
Ok, playing with this a bit more (using DateTime 0.13) makes me confused:
--
my $d = DateTime::Duration->new(hours => -3, minutes => 57, seconds => 2);
--
Gives 'minutes' => -123, 'seconds' => -2.
--
my $d = DateTime::Duration->new(hours => 3, minutes => -57, seconds => 2);
--
Gives 'minutes' => -123, 'seconds' => -2.
BUT
--
my $d = DateTime::Duration->new(hours => -3, minutes => -57, seconds => 2);
--
Gives 'minutes' => -237, 'seconds' => -2.
AND
--
my $d = DateTime::Duration->new(hours => 3, minutes => 57, seconds => -2);
--
Gives 'minutes' => -237, 'seconds' => -2.
I am totally mystified. I read "If any of the numbers are negative,
the entire duration is negative." as indicating that the individual
signs don't matter.
I think the error is on DT::Duration line 52:
$self->{minutes} = abs( ( $p{hours} * 60 ) + $p{minutes} ) * $self->{sign};
Which should perhaps be:
$self->{minutes} = ( abs( $p{hours} * 60 ) + abs( $p{minutes} ) ) * $self->{sign};
-ben
DateTime::Duration nits...
I want to create a duration that represents 3 hours shy of 3 months. There is no way to do this directly using the new() constructor (Date::Manip has 2 effective signs, one on years and months and the other on weeks, days, hours, minutes and seconds). You can get this by doing: -- my $dur = DateTime::Duration->new(months => 3); $dur->add(hours => -3); -- The nits: 1) The following doesn't work because add_duration() doesn't return the object, but rather falls through and returns the number of nanoseconds in the final object: -- my $dur = DateTime::Duration->new(months => 3)->add(hours => -3); -- 2) Having a way to construct this directly would be nice being able to make a duration that you can not directly construct seems odd. -ben
Re: Problems with DateTime::TimeZone->short_name_for_datetime()
Oh. Duh. I took the line "This class has the following methods" to mean that it was a class method not an object method. Dunno why I read it like that, everything is pretty clearly intended to be called through an object. Anyway, DateTime's time_zone_short_name method was actually what I should have been using since I don't have a TZ object the TZ should be able to tell me it's short name... Thanks, -ben On Wed, Jun 25, 2003 at 01:50:39PM -0500, Dave Rolsky wrote: > On Wed, 25 Jun 2003, Ben Bennett wrote: > > > my $short = DateTime::TimeZone->short_name_for_datetime($dt); > > This is an object method, not a class method. > > > On a related note, while trying to chase this problem I noticed that > > DT::TZ->span_for_datetime() compares $type to "UTC" to determine $end, > > but all of the callers are passing in "utc". > > That's a bug. Now I just need to figure out how to test it. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Problems with DateTime::TimeZone->short_name_for_datetime()
Code that exhibits the problem:
--
#!/usr/local/bin/perl -w
use strict;
use DateTime;
use DateTime::TimeZone;
my $dt= DateTime->new(year => 2003, month => 6, time_zone => "America/New_York");
my $short = DateTime::TimeZone->short_name_for_datetime($dt);
print "$short\n";
--
The error:
--
Can't use string ("DateTime::TimeZone") as a HASH ref while "strict refs" in use at
/usr/lib/perl5/site_perl/5.8.0/DateTime/TimeZone.pm line 287.
--
On a related note, while trying to chase this problem I noticed that
DT::TZ->span_for_datetime() compares $type to "UTC" to determine $end,
but all of the callers are passing in "utc".
-ben
Re: DT::F::Builder multiple identical lengths
I know you can mix them, but I would prefer to match completely since as I said there is a decent speed win. The fact that multiple formats can match is irrelevant here (that is dealt with when filtering by type). It might be useful to someone to be able to get the parts of the given string back in a hash so that they can see what pieces were not specified (in the case of a reduced format). Also in the case of Time only formats, it is a bit of a hack to massage them into a DateTime, so it may be more useful to get the parsed pieces back to use in another way. Also the recurrence format Rn/PnYnMnDTnHnMnS is tricky since the start date and time are not specified. I plan on handling that the same way that I do with the time components and using the date the user passed in or DT->now() if none was specified... However, I may want to get at the parts of the recurrence from the calling code. -ben On Wed, Jun 25, 2003 at 07:04:05AM -1000, Joshua Hoblitt wrote: > On Wed, 25 Jun 2003, Ben Bennett wrote: > > > All true... but my benchmarking as I wrote my ISO8601 showed that the > > speed gained by pre-filtering by length to reduce the number of > > regexps that need to be tried is substantial. > > You can mix length with no-length specrefs. > > > The other thing that my ISO8601 parser does is (optionally) return the > > format specification and pieces of the time string (because it is not > > always possible to cleanly map an ISO8601 string into a DT, but the > > module tries its best). Is there a way to easily do that with Builder > > that I haven't spotted yet? > > Theres only 6 strings that can match either dates or time. > > hhmmss > hhmm > hh > -mmss > -mm > --ss > > -J > > --
Re: DT::F::Builder multiple identical lengths
All true... but my benchmarking as I wrote my ISO8601 showed that the speed gained by pre-filtering by length to reduce the number of regexps that need to be tried is substantial. I will have to look into the dispatch stuff... The other thing that my ISO8601 parser does is (optionally) return the format specification and pieces of the time string (because it is not always possible to cleanly map an ISO8601 string into a DT, but the module tries its best). Is there a way to easily do that with Builder that I haven't spotted yet? -ben On Wed, Jun 25, 2003 at 06:09:50AM -1000, Joshua Hoblitt wrote: > On Wed, 25 Jun 2003, Ben Bennett wrote: > > > On Wed, Jun 25, 2003 at 06:53:10PM +1000, Iain Truskett wrote: > > > * Joshua Hoblitt ([EMAIL PROTECTED]) [25 Jun 2003 17:59]: > > > > > > > But what if I use /(-?\d\d\d\d)/ as the regex and set the > > > > length => [ qw( 4 5 ) ]? :) > > > > > > cvs update > > > > > > Your wish is my small patch. > > > > While you are fiddling with the lengths... > > > > Ok. One of the reasons that I am not using Builder is for the length > > greater than N cases... > > > > For example ISO8601 has fractional formats, e.g.: > > HH:MM:SS.... > > You don't have to match by length. My current first release of ISO code handles the > fractional formats. Although it's using a , as the separator. It isn't clear to > me if ISO means ( just . or , and . as separators). > > > I want to be able to say this is a valid match if the length is 10 or > > more characters. > > Thats what regex is for. > > > Of course the other reason that I am not using Builder at the moment > > is that I allow the user to specify the types of formats that they > > want to consider and making that work in the Builder framework seemed > > to be more trouble than it was worth. > > The dispatch mechanism should allow this. > > -J > > --
Re: DT::F::Builder multiple identical lengths
On Wed, Jun 25, 2003 at 06:53:10PM +1000, Iain Truskett wrote: > * Joshua Hoblitt ([EMAIL PROTECTED]) [25 Jun 2003 17:59]: > > > But what if I use /(-?\d\d\d\d)/ as the regex and set the > > length => [ qw( 4 5 ) ]? :) > > cvs update > > Your wish is my small patch. While you are fiddling with the lengths... Ok. One of the reasons that I am not using Builder is for the length greater than N cases... For example ISO8601 has fractional formats, e.g.: HH:MM:SS.... I want to be able to say this is a valid match if the length is 10 or more characters. Of course the other reason that I am not using Builder at the moment is that I allow the user to specify the types of formats that they want to consider and making that work in the Builder framework seemed to be more trouble than it was worth. -ben
Re: What's up with DT::TZ::Alias?
Yeah, I know. That is what rang the initial warning bell. Frankly the functionality provided by Alias seems to be vital to the TZ package anyway. (Kudos for writing it). -ben On Mon, Jun 23, 2003 at 10:11:02AM -1000, Joshua Hoblitt wrote: > > A little voice has been saying that ever since I saw that Alias was > > reaching into the TZ aliases directly. > > There's a warning about this in the pod. :) > > -J > > --
Re: What's up with DT::TZ::Alias?
On Mon, Jun 23, 2003 at 12:34:13AM -0500, Dave Rolsky wrote: > > Also, I'm not entirely against the idea of folding all the alias stuff > into the main DT::TZ module. It doesn't seem like an entirely wack idea, > though I'd be glad to hear why I'm wrong ;) I think this is the right thing to do. A little voice has been saying that ever since I saw that Alias was reaching into the TZ aliases directly. -ben
Re: Getting different results from DateTime and Manip for epoch time
Fantastic! Thank you for the summary, I will add it to the FAQ (with appropriate attribution of course). -ben On Sun, Jun 22, 2003 at 10:36:02PM +, [EMAIL PROTECTED] wrote: > Thanks Eugene. > > I'll try to rephrase this, because it > would be good to have it in the FAQ. > If somebody can explain it better, or > more correctly, please help me! > > What's up with GMT, TAI, UTC, and UT1? > > Before 1972, the "international time" reference > was GMT. In GMT, all days have the same number > of seconds. A day starts at "midnight" and has > 86400 seconds. > > TAI is another time measuring system, in > which seconds depend on "atomic time" only, > instead of the Sun-Earth position. > TAI days have 86400 seconds, and it's > origin is in 1958 January 1. > > Parallel with those, there exists UT1, which > is the "astronomical time". > UT1 depends only on Sun-Earth position. > UT1 - TAI is some fractional seconds. > > In 1972 UTC was introduced, in order to > approximate "international time" to > "astronomical time". > Now, whenever the difference between UTC and > UT1 is big enough, a leap second is introduced. > UTC is synchronized to TAI, which means that > UTC - TAI is an integer number of seconds. > UTC - UT1 is some fractional seconds. > > > [EMAIL PROTECTED] schreef: > > > > http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond. > > > html > > > > > > "... Since the system was introduced in 1972, " > > > > > > The table starts in 1972. Before that, GMT was > > > in use - not UT1! > > > > Not true. UT1 existed at least since 1958. In that > year, TAI (atomic > > time) was synchronized with UT1. > > > > UT1 is based on the observed length of the day > (corrected for some > > large scale effects like the movement of the > poles). As it is > > observation based, it is not a good timescale to > base civil time on. > > UT was used for that. Periodically the > correspondence of UT and UT1 was > > checked, and UT was corrected by changing the > length of the day, and by > > adding a small time adjustment to account for the > accumulated > > difference. > > > > Civil time was based on UT: GMT was UT+, MET > was UT+0100, EST was > > UT-0500 IIRC (as long as you're not in Australia). > > > > So the role of UT/GMT was taken over by UTC, not by > UT1. > > > > Eugene > > >
Re: www docs
Check out Dave's work on the POD to HTML stuff for the FAQ for a start... -ben On Sun, Jun 22, 2003 at 06:41:16PM -0500, Dave Rolsky wrote: > On Sun, 22 Jun 2003, Dave Rolsky wrote: > > > On Sun, 22 Jun 2003, Joshua Hoblitt wrote: > > > > > Should I add the namespaces doc to web/htdocs/developer/? > > > > Sure, please do. > > BTW, you should use Pod::Simple::HTML for the conversion, not pod2html > that comes with Perl. The latter produces really icky output that needs > _lots_ of editing to clean up. The former is much easier to convert into > a Mason component for the DT site. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: Business Dates
I used to live in Saudi Arabia and the weekend was on Thursday and Friday (I don't know what calendar businesses used but I will ask my father). -ben On Sun, Jun 22, 2003 at 01:37:24AM -0500, Dave Rolsky wrote: > On Sun, 22 Jun 2003, Eugene van der Pijll wrote: > > > Businesses in Israel, Iran and in the Arab world probably use a business > > calendar based on the Hebrew, Jalali and Hijira calendars. It would be > > nice if one module could be used for the Gregorian calendar and for > > these three calendars. > > Actually, I'd guess they use a business calendar where the work week is > still Monday - Friday (or through Saturday), but where _holidays_ are > determined by a given religion, which in turn uses a different calendar. > > But nonetheless, days of the week and days of the month are still going to > be Gregorian. I doubt that businesses in Israel refer to dates by the > Hebrew calendar. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
Re: Standalone Times?
On Sun, Jun 22, 2003 at 04:47:42AM +0200, Eugene van der Pijll wrote: > > If YY really is the century, you should probably return Jan 1st, 1901 > when given 20... The example given in the spec says that given "12 April 1985" YY gives 19. So they are being a little loose with the word century... -ben
Rough ISO8601 parser ready...
I have made my rough ISO8601 parser available at: http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz Since this is a rough first release there are huge things wrong with it. An incomplete list is: - No documentation - Module name not settled yet - Only parses Dates (no times, recurrences or durations... yet) - Code is littered with XXX indicating areas of further thought - Code is littered with debug stuff - Code should be much cleaner before release - The interface is nowhere near done - Needs more tests (and tests of failure) - Error handling doesn't exist What it does do at the moment: - Parses any valid ISO8601 date - Allows you to pick which format categories to apply (but the interface is awful!) - Does selection by variable length (8+ characters) - Reasonably efficient algorithm for picking which formats match the user's categories - Test suite works now (and is passed completely) If you want to play with this either check out the test suite, or use the following line as a basis: PERL5LIB=lib perl -MDateTime::Format::ISO8601 -e 'print DateTime::Format::ISO8601->parse_datetime(shift, shift)->datetime(), "\n"' 2003W011 The optional second argument is the formats to use. The valid formats are: C: Complete (fully specified date) R: Recuced Precision (less significant items are dropped) T: Truncated (current items implied) B: Basic (no separators) E: Extended (with separators) X: Expanded (extra years) O: Ordinal date (day count from year) W: Week date (day count from year) The default is to try all of them (XWOTCREB). You must always pass in E or B and C or R since each format has those types. So if you only wanted to use Complete Basic items, pass in "CB". -ben
Re: [rfc] DateTime::Util
I saw that mail, but I meant yet another constructor that will take an ISO week number and day number (within the week) and a "year" construct the appropriate date. Note that the year given may not be the actual year the date falls in but is rather the ISO year number. (For instance day 1 of week 1 of 2003 is 2002-12-30!) You can manaully do this by doing: -- my $dt = DateTime->new(year => $year, month => 1, day => 4); my $adjustment = ( ($week_num - 1) * 7 ) + ( $day_num - 1 ) - ( $dt->day_of_week - 1 ); $dt->add($adjustment); -- -ben On Fri, Jun 20, 2003 at 05:08:09PM -1000, Joshua Hoblitt wrote: > On Fri, 20 Jun 2003, Ben Bennett wrote: > > > Is this for taking an ISO week number and day of week and getting a > > month, day and year back? > > > > Dave, would it be possible to have a DT constructor for this? There > > is an accessor (week()) that does the reverse... For the ISO8601 > > module it would be nice to have this, although it is easy enough to do > > by hand. > > I still think there might be a need for DT::Util but for this case (I was thinking > of ISO8601 as well) there is another constructor. > > To quote Dave: > > Date: Fri, 20 Jun 2003 16:09:42 -0500 (CDT) > From: Dave Rolsky <[EMAIL PROTECTED]> > > To: Ben Bennett <[EMAIL PROTECTED]> > Cc: Rick Measham <[EMAIL > PROTECTED]>, "Hill, Ronald" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'" <[EMAIL > PROTECTED]> Subject: Re: Having problems with Datetime-format-Strptime-1.02 install > on Wi n32 > > On Fri, 20 Jun 2003, Ben Bennett wrote: > > >> Personally I think this is a good reason to either add a > new> DateTime > constructor or to add the flag that relaxes the parameter > > validation and allows rollovers. > > >There is a DateTime->from_day_of_year > constructor. > > > > -dave > > > /*=== > House Absolute > Consulting > www.houseabsolute.com > > ===*/ >
Re: [rfc] DateTime::Util
Is this for taking an ISO week number and day of week and getting a month, day and year back? Dave, would it be possible to have a DT constructor for this? There is an accessor (week()) that does the reverse... For the ISO8601 module it would be nice to have this, although it is easy enough to do by hand. -ben On Fri, Jun 20, 2003 at 12:11:22AM -1000, Joshua Hoblitt wrote: > As I'm thinking about normalizing week + day numbers to month + day numbers I'm > wondering if there shouldn't be a module for all such common (to DT modules) > conversion functions? Comments? > > -J > > --
Re: Business Dates
I am still in the thinking about this phase... I am not sure what your mean by 'logical progression' etc. Do you mean the current state or the ideal future state that the frightening email thread alludes to? I was under the impression that the Pataphysical calendar was basically a fictional one that parodies the French Catholic calendar (http://user.icx.net/~richmond/rsr/pataphysique/pataphysique.html). Are you suggesting that it is useful for business calculations? Your point about the variable fiscal year start dates is a good one though. We definitely need to take that into account. -ben On Fri, Jun 20, 2003 at 11:50:20AM -0400, Jesse Shy wrote: > I read the thread as you suggested Ben; now I am veryh afraid. Is anyone > working on any of this? I am interested in not only what I descibed > earlier, but also the stuff concerning contracts and billing periods... > and later the work rules stuff. Are there any lists or diagrams that show > what can be built on top of what exist and a logical progression how to > get to some of the more speciallized aspects? > > I think what I proposed earlier may be a good start and could have a > method like > > ::use_calendar( 'Gregorian' ) or Pataphysical etc... > > Then do day week calculations to come up with that type of calendar > adjusted. A Gregorian calendar still has the same number of weeks and days > only with the begining and ending dates realigned. > > I could be wrong though.
Re: RFC: Fiscal Dates
No, you aren't blind, the archives at 'http://archive.develooper.com/[EMAIL PROTECTED]/' appear to be missing a lot of stuff. Does anyone know what is going on? Try using 'http://nntp.x.perl.org/group/perl.datetime' for the moment. The particular thread starts at: http://nntp.x.perl.org/group/perl.datetime/2714 But there is no threading support on that server unless you use the news interface (and the thread goes on for a while). -ben On Fri, Jun 20, 2003 at 08:30:52AM -0400, Jesse Shy wrote: > I apologize if I am blind, I looked in the archives and did not see the > thread for business calculations. Was this the topic or did it start from > something else. Thanks. > >
Re: RFC: Fiscal Dates
There was a recent disussion about what a business date module should be able to do that might be interesting if you want to make this module do other business calculations... -ben On Fri, Jun 20, 2003 at 08:00:17AM -0400, Jesse Shy wrote: > > I currently have a subclassed module I created for an application here at > work, called Date::Calc::Fiscal. The interface takes 2 dates, the fiscal > start date and the date your interested in - returning either the day > number or week number of the fiscal year. So if your fiscal start day is > Feb 1, then Feb 1 is day 1 of week 1, or iso I guess is week 0 and Jan 31 > is day 365 or 366 depending. We use this in a web app to show individual > customers their invoicing by periods that match their internal accounting > practices. > > After some thought, I realized that this was simply the application and > that the function is realy a numerical day adjustment to either the > gregorian or pataphysical calendars, depending on whether you have 12 or > 13 periods in calender ( fiscal instrument ). > > So first I am wondering about namespace. I can not think of another place > where this is needed other than finacial apps, so I was thinking > DateTime::Fiscal, but as I said earlier, that is really the application > not the function however, if this is the only application than this name > fits. > > Currently I only have 2 methods, day_of_fiscal_year and > week_of_fiscal_year. I would eventually like to use DateTime::Set, ::Span > ::SetSpan along with calendaring to create fiscal calendars showing end of > period dates, etc... > > I would love some feedback on these thoughts or anything related to this > that I may not have thought of. Thanks.
Re: Having problems with Datetime-format-Strptime-1.02 install on Wi n32
Personally I think this is a good reason to either add a new DateTime constructor or to add the flag that relaxes the parameter validation and allows rollovers. -ben On Fri, Jun 20, 2003 at 09:12:38AM +1000, Rick Measham wrote: > At 1:19 PM -0700 19/6/03, Hill, Ronald wrote: > >I am running the CVS versions of DateTime/DateTime-TimeZone for perl 5.6.1 > > > >Any thoughts? > > Yup, DateTime on CVS wont work. Which reminds me that I need to > supply Dave with another patch before he releases the new DateTime. > > [Explaination: DateTime now requires a valid date. Strptime for > day-of-year initiates DateTime with a year=>$year month=>1 and > day=>$day-of-year] > > > Cheers! > Rick
Re: ISO 8601 is eeeevil!
I will try to have something usable by tomorrow... I made some decent progress last night. -ben On Fri, Jun 20, 2003 at 01:08:13PM +1000, Iain Truskett wrote: > * Ben Bennett ([EMAIL PROTECTED]) [20 Jun 2003 12:59]: > > On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote: [...] > > > When I started writing DateTime::Format::ISO8601 I was using the > > > ordering method. Although I think it maybe necessary to to use both > > > 1 and 2. Someday I may finish this module - what name are you > > > planning on using? > > > I was thinking about DateTime::Format::ISO8601... unless you have laid > > claim to it. > > > I don't know if I will manage to finish this thing, it is a bit of a > > monster. > > Perhaps one of you should add it to the CVS server as-is and both work > on it? > > > cheers, > -- > Iain.
Re: ISO 8601 is eeeevil!
On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote: [...] > > When I started writing DateTime::Format::ISO8601 I was using the ordering method. > Although I think it maybe necessary to to use both 1 and 2. Someday I may finish > this module - what name are you planning on using? I was thinking about DateTime::Format::ISO8601... unless you have laid claim to it. I don't know if I will manage to finish this thing, it is a bit of a monster. -ben
Re: ISO 8601 is eeeevil!
Well that was always my intention. I plan to allow the caller to specify what exact rules to use since the spec basically allows very little unless the parties agree. However, I think that the default format (if nothing was specified) should allow for parsing of common ISO8601 formats. This need not be settled yet, I will try to get the module out so people can better see what I have in mind and critique "working" code. -ben On Thu, Jun 19, 2003 at 11:35:58AM -0700, Bruce Van Allen wrote: > An interesting challenge here might be to devise a way to allow DateTime to exploit > the full range of ISO 8601 formats, in cases where the user knows that the > appropriate agreements exist among the parties. > > Perhaps a DT::F::ISO8601 parameter like >accept => ['DDD'], > could be used, evoking the necessary routines to parse & format. (I put this in the > form of an array ref to handle multiple accepts.) > > Just a thought. > > - Bruce
ISO 8601 is eeeevil!
Ok. So ISO8601:2000 defines all sorts of things, some of which are impossible to distinguish from one another without outside information: +yMMDD Extended complete year +yDDD Extended ordinal day in year -YYMM Year and month in implied century -DDDOrdinal day in implied year -YY Year in implied century +y Extended year +yYYExcended century Notation: -: - Character Y,M,D: Year, month, day digit respectively +: + or - characters The root of the collisions is the arbitrary number of extended digits (which may be 0, so you could have -0101, now is that the year 102 BC, or January in 2001? The extended formats also collide internally, i.e. what is the date +1985? Is it a century or a year? The choices for resolving this are to: 1) Never allow an extended representation (even for +s which can't collide externally) unless the user tells us to use it and specifies the digits 2) Use the ordering above to break ties I am leaning towards choice 2 for this, but things are not completely dire since I plan to allow the user of the module to pick which categories of formats to allow (and to specify how many digits are in an extended date). There are also collisions with time strings, but those are resolvable with the following rules (stopping with the first rule that fits): - It is what the user says it is - If there is a T prefix - If there is a TZ (Z or offset) - If there are : separators - Otherwise assume it is a date -ben
Re: utc_rc_values nanosecond support
On Wed, Jun 18, 2003 at 10:14:32AM -1000, Joshua Hoblitt wrote: > Hi Dave, > > Two questions: > > 1) When is fractional second support going to be dropped? Already dropped in CVS. So whenever the next release happens... I agree that we need to fix the ns support when switching calendars. -ben
Re: What should a business module implement?
Is that a generic business calculation or just an application of sets?
I think the latter. You can just make a set representing the
intersection of mondays (or weekdays) and Dec. 31sts. Then iterate
over it (using the restricted time range) to find the solution.
--
use strict;
use DateTime;
use DateTime::Event::Recurrence;
my $dec32 = DateTime::Event::Recurrence->yearly
(months => 12, days => 31);
my $mondays = DateTime::Event::Recurrence->weekly
(days => 1);
my $s = $dec32->intersection($mondays);
my $i = $s->iterator(start => DateTime->new(year => 2000),
end => DateTime->new(year => 2008));
while (my $d = $i->next) {
printf "%s - %s\n", $d->day_name(), $d->datetime;
}
--
Prints:
--
Monday - 2001-12-31T00:00:00
Monday - 2007-12-31T00:00:00
--
-ben
On Tue, Jun 17, 2003 at 01:39:00PM -1000, Joshua Hoblitt wrote:
> What if I wanted to know inside a range of years which had a December 31st that was
> on a Monday (or on a weekday)?
>
> -J
>
> --
Re: [announce] DateTime::TimeZone::Alias 0.01 (fwd)
Ok. It is your module so this is your call.
I disagree, but that is ok. This should end the thread.
-ben
On Tue, Jun 17, 2003 at 01:26:43PM -1000, Joshua Hoblitt wrote:
> > my $dta = "DateTime::TimeZone::Alias";
> >
> > $dta->remove("EST");# Start with a clean slate
> > $dta->add("EST" => "US/Eastern"); # Succeeds
> > $dta->add("EST" => "US/Eastern"); # Succeeds
> > $dta->add("EST" => "America/New_York"); # Succeeds
> > $dta->add("EST" => "America/Chicago"); # Fails
> > --
>
> I know what your asking for but I don't like the behavior. This would be
> non-intuitive for most users, including me. Calling add more then once to perform
> the same action is a logic error.
>
> Cheers,
>
> -J
>
> --
Re: [announce] DateTime::TimeZone::Alias 0.01 (fwd)
On Tue, Jun 17, 2003 at 09:52:46AM -1000, Joshua Hoblitt wrote:
>
> Btw - US/Eastern is defined as an alias unless you removed it earler in the program.
>
Yeah, that is why I have to jump through more hoops in my example.
> How would an add method that returns silently if an alias is already defined tell if
> an alias has been redefined somewhere else?
It _only_ returns silently if the current definition matches the
real timezone of the requested definition:
--
my $dta = "DateTime::TimeZone::Alias";
$dta->remove("EST");# Start with a clean slate
$dta->add("EST" => "US/Eastern"); # Succeeds
$dta->add("EST" => "US/Eastern"); # Succeeds
$dta->add("EST" => "America/New_York"); # Succeeds
$dta->add("EST" => "America/Chicago"); # Fails
--
> If you mean;
[...]
> Then say it.
Neither are what I mean. Hopefully my example above clarifies things...
-ben
Re: date normalization
I have actually been thinking about that a bit... The way it is shaping up is that it will be a generic DT::SpanSet wandering thing... So given a SpanSet (or Set, or Span) it will be able to do operations within its context (i.e. date arithmetic, etc.). DT::E::BusinessDay would simply be a superclass of this (as yet unnamed) base class that would define some business specific functions (and possibly aliases for some methods). -ben On Mon, Jun 16, 2003 at 09:56:11PM -1000, Joshua Hoblitt wrote: > > Hang on a second .. isn't this all a part of DateTime::Event::BusinessDay? > > Maybe BusinessDay doesn't describe the functionality all that well then. :)
Re: [announce] DateTime::TimeZone::Alias 0.01
I think DateTime::TimeZone::Alias 0.03 is really looking good. The
docs are excellent (small patch to fix typos included below).
I really like the new is_X subs, although in the case of the
is_alias() would it make sense to return the target of the alias?
i.e. If I have aliased EST to America/New_York, could it return
"America/New_York" rather than 1? Both are true so it should be
equivalent, but being able to get the mapping seems useful. Although
if I had EST => US/Eastern, then what should it return? I argue that
it should still return America/New_York since that is the base time
zone.
Finally I still think that not throwing an error if add()ing a
duplicate definition makes sense (although I agree that croak()ing is
the right thing to do). I would like to be able to do:
--
my $dta = "DateTime::TimeZone::Alias";
$dta->add(EST => "US/Eastern");
...
$dta->add(EST => "US/Eastern"); # This should be OK
$dta->add(EST => "US/Central"); # This should croak
--
(In fact an add("America/New_York" should also not die). My theory
being that people may have a sanity check in a few places to make sure
the right TZ mappings are defined. For instance at work we use Mason
running in mod_perl under Apache, so the same environment persists
across different pages. If one page does the add() I wouldn't want a
subsequent page to have to jump through hoops to check the definition
of the alias is correct if doing an equivalent add()... I don't think
we lose anything by allowing a subsequent add() to silently be skipped
if it is the same.
One last thing, I just realized that the subs expect to be called as
class methods. This is fine unless you want to alias them into your
package (or accidentally call them like DateTime::TimeZone::Alias::add()).
The following fails:
--
use DateTime::TimeZone::Alias;
*set_tz = \&DateTime::TimeZone::Alias::set;
set_tz(EST => "US/Eastern");
--
I don't know if it is exactly an error, but it is a little annoying.
You could "fix" it by checking the argument count but that doesn't
handle remove()... also it will fail if someone wants to superclass
this class since add calls set through the class. I have no idea if
there is a general solution to this problem, someone must have hit it
before though.
Cool stuff, Nice work!
-ben
The POD diff:
--
--- Alias.pod.orig 2003-06-16 21:52:23.0 -0400
+++ Alias.pod 2003-06-16 21:52:59.0 -0400
@@ -48,7 +48,7 @@
Accepts a hash representing an alias and the timezone it should map too.
If an invalid timezone value is passed an exception is thrown.
It is possible to create an alias to another alias. This method will
-redefined an existing alias or add a new alias that overrides an existing
+redefine an existing alias or add a new alias that overrides an existing
timezone.
=item * add( alias => timezone, ... )
@@ -56,7 +56,7 @@
Accepts a hash representing an alias and the timezone it should map too.
If an invalid timezone value is passed an exception is thrown.
It is possible to create an alias to another alias.
-This method will _not_ redefined an existing alias or allow you remap a
+This method will _not_ redefine an existing alias or allow you remap a
timezone. For redefinitions see the C method.
=item * remove( alias, ... )
Re: date normalization
Ah! nice. I don't fully understand DT:E:Recurrence yet...
Slight correction to both scripts:
The hours should be 13 and 17 instead of 1 and 5 (damn PM...).
Then yours should be (otherwise it picks up Saturdays too):
days => [1..5]
Which is more clear than mine anyway...
-ben
On Mon, Jun 16, 2003 at 11:49:16PM +, [EMAIL PROTECTED] wrote:
> Joshua Hoblitt said:
> > There must be a way to express the same semantic
> > meaning with fewer lines of code
>
> A slightly smaller version - specify days and hours
> in the same constructor.
>
> - Flavio S. Glock
>
> ---
> #!/usr/local/bin/perl -w
>
> use strict;
> use DateTime;
> use DateTime::Span;
> use DateTime::SpanSet;
> use DateTime::Event::Recurrence;
> use Carp;
>
> # Make a set representing mondays to fridays, with
> # the working hour restriction
> my $working_days =
> DateTime::SpanSet->from_sets
> (start_set => DateTime::Event::Recurrence->
>weekly( days => [1..6],hours => [9, 1]),
>end_set => DateTime::Event::Recurrence->
>weekly( days => [1..6],hours => [12, 5]),
> );
>
> # Make the date range
> my $date_range = DateTime::Span->from_datetimes
> (start => DateTime->new(
> year => 2003, month => 7, day => 1),
> end => DateTime->new(
> year => 2003, month => 7, day => 18));
>
> # Build the spanset of legal times
> my $legal = $working_days->intersection($date_range);
>
> ## Test code
> my $iter = $legal->iterator();
> while ( my $dt = $iter->next ) {
> printf "%s to %s\n",
>$dt->start->datetime,
>$dt->end->time;
> };
> ##
>
> # Now test the date
> my $dt = DateTime->new(year => 2003);
> croak "Bad date range" unless $legal->contains($dt);
>
Re: date normalization
Ok, lets say that you want only "working hours" as legal times, so
9-12,1-5, M-F from July 1st to July 17th, 2003.
Most of the code below is building the ranges... I think youy would
have to do that anyway. The real bit that the module would do is the
intersection stuff, and that is a couple of lines.
I have included some test code to print out the legal ranges.
-ben
--
#!/usr/local/bin/perl -w
use strict;
use DateTime;
use DateTime::Span;
use DateTime::SpanSet;
use DateTime::Event::Recurrence;
use Carp;
# Make a set representing mondays to fridays
my $working_days =
DateTime::SpanSet->from_sets
(start_set => DateTime::Event::Recurrence->weekly(days => 1),
end_set => DateTime::Event::Recurrence->weekly(days => 6),
);
# Make the working hour restriction
my $working_hours =
DateTime::SpanSet->from_sets
(start_set => DateTime::Event::Recurrence->daily(hours => [9, 1]),
end_set => DateTime::Event::Recurrence->daily(hours => [12, 5]),
);
# Make the date range
my $date_range = DateTime::Span->from_datetimes
(start => DateTime->new(year => 2003, month => 7, day => 1),
end => DateTime->new(year => 2003, month => 7, day => 18)); # 1-17 inclusive
# Build the spanset of legal times
my $legal = $working_days->intersection($working_hours)
->intersection($date_range);
## Test code
my $iter = $legal->iterator();
while ( my $dt = $iter->next ) { # $dt is a DateTime::Span
printf "%s to %s\n", $dt->start->datetime, $dt->end->time;
};
##
# Now test the date
my $dt = DateTime->new(year => 2003); # Your date here
croak "Bad date range" unless $legal->contains($dt);
--
On Mon, Jun 16, 2003 at 08:42:14AM -1000, Joshua Hoblitt wrote:
> > my $safe_span = ...;# Whatever you need
> > my dt = DateTime->new(...);
> > croak "Bad date range" if $safe_span->contains($dt);
>
> In my [poor] example. But what if you only wanted to only accept time values from
> 11:00-18:00 across a span?
>
> > In fact you may want the span to be a spanset to accomodate more fine
> > grained controls. Is this useful enough to merit a class? I dunno.
>
> I think it could be useful - I'm just not that sure about the syntax.
>
> Cheers,
>
> -J
>
> --
Re: milli/micro seconds
Dave already said that he was open to adding a flag to control the overflow behavior if anyone could provide a valid reason for needing it. It sounds like you have a good reason, so post it and see if he will add the flag. -ben On Mon, Jun 16, 2003 at 08:43:50AM -1000, Joshua Hoblitt wrote: > Hi Rick, > > > Cool idea .. and I'll add DateTime::Wrapper::AllowThingsToOverflow > > (or something shorter) that allows you to construct with overflowing > > parameters (like 75 seconds, 124 minutes, 34 hours, 98 days and 16 > > months) > > Are you still going to do this? I already want to subclass it for something. :) > > -J > > --
Re: date normalization
Isn't that simply: my $safe_span = ...;# Whatever you need my dt = DateTime->new(...); croak "Bad date range" if $safe_span->contains($dt); In fact you may want the span to be a spanset to accomodate more fine grained controls. Is this useful enough to merit a class? I dunno. As a minor note, it might be nice to be able to chain the Wrappers, but I have no idea what syntax one would use. -ben On Sun, Jun 15, 2003 at 04:15:49PM -1000, Joshua Hoblitt wrote: [snip] > > However - I was thinking of a validator that could be configured with input ranges > for each parameter. > > Example: > > $start = DateTime->new( year => 1939 ); > $end = DateTime->new( year => 1945 ); > $year_span = DateTime::Span->from_datetimes( start => $start, end => $end ); > > my $dtvdator = DateTime::Wrapper::Validator->watch( year => $year_span ); > > # creates a DT object > my $dt = $dtvdator->new( year => 1944 ); > > # throws an exception > my $dt = $dtvdator->new( year => 1938 ); > > I'm kinda fuzzy on watch the syntax (or what the method name should be). > > -J > > -- >
Re: date normalization
On Mon, Jun 16, 2003 at 12:01:21PM +1000, Iain Truskett wrote: > > That version isn't on CPAN yet. To be honest, I'd really > like the validation to be optional. While some people have > more use for validation rather than normalization, others > (like me) are the opposite =) I half agree. Initially I thought that it should be optional and said so on the list. Dave replied saying that he wouldn't make it so unless anyone had an example of why it needed to be optional. So far I haven't come up with a reasonable one. If you have a real case mail it to the list. -ben
qr// in 5.00503 [was: Re: Converting to DT]
I knew I had seen the assertion that qr started in 5.6.0 somewhere recently and finally found it: "Perl 5.6.0 introduced the ability to package up regular expressions into variables using the qr// operator." [From Simon Cozen's article on regexps http://www.perl.com/pub/a/2003/06/06/regexps.html] So... given that you have it working on 5.00503 he is clearly in error. Does anyone know of a quick reference to show what new syntax was introduced with a given release? -ben On Wed, Jun 11, 2003 at 04:59:08PM -0500, Dave Rolsky wrote: > On Thu, 12 Jun 2003, Rick Measham wrote: > > > At 4:28 PM -0500 11/6/03, Dave Rolsky wrote: > > >5.00503 is the goal for all DateTime modules, and anyone writing a DT > > >module should have a damn good reason for _not_ supporting it. qr// does > > >indeed work with 5.00503. > > > > > > Since when? > > > > "This is perl, version 5.005_03 built for i386-freebsd" > > > > I went through seven stage of hell trying to get it installed. IIRC I > > had to hack Time::Local. Can't remember though, all I remember is > > that it wasn't just a case of perl Makefile.PL, make, make test, make > > install. > > > > Does anyone have a legacy system they can try to install on? > > Yeah, me. DT.pm uses qr// internally and I always run tests on 5.00503, > 5.6.1, and 5.8.0 before each release. > > > -dave > > /*=== > House Absolute Consulting > www.houseabsolute.com > ===*/
