Re: Timezone Problem
Harder, Paul wrote: You'd think there'd be a database somewhere that gives the time zones of all airports. There used to be, but updates to it are no longer being issued. Failing that, I could try the more general problem of determining zone based on city, state and country names. But I have found no help there either. If you have the actual addresses, you can use a zipcode database like this one: http://zipinfo.com/products/products.htm You might also find some useful information in this thread: http://answers.google.com/answers/threadview?id=707918 HTH 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
Best practices - DateTime vs Database question
I'm in the planning stages for a membership database (probably using Catalyst) to replace InfoCentral (worst-case PHP spagetti code, since massively hacked by yours truly). One feature I want to improve upon is the calendar. Since this is going to be for my synagogue, I need to also display Hebrew dates. My questions are: 1) What should I store in the database? a) Native MySQL DATETIME field? b) Three fields representing Rata Die? c) Julian number (this is easier to convert to Hebrew Date)? d) Month/Day/Year INT fields 2) Should I use DateTime at all, since primarily I am interested in events scheduled for a specific date (time is not necessarily important)? The most common operation on a date for this purpose is how many weeks until event X so I can display the next week's events or send out scheduling e-mails prior to events. Thoughts? 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: Best practices - DateTime vs Database question
Dave Rolsky wrote: If you need to translate Hebrew dates into Gregorian dates, which I assume you do, then I'd think DateTime would help with that. The other way round, actually. The calendar has to correspond to the current common calendar, and I want to display the corresponding Hebrew dates, too. I may just wind up using libhdate: http://libhdate.sourceforge.net/ (which has Perl bindings) because it also gives me the parasha (weekly readings) and sundown times for free. I just wanted to keep an open mind as to whether DateTime had some specific benefit to this project. 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: DateTime::TimeZone in XS is ready in CVS
Daisuke Maki wrote: I'm thinking the memory inefficiency + the way util.o is one of the culprits. let me try a few tests... Just FYI, it has recently come to my attention that code like yours (and my version.pm code) won't compile properly under GCC 4.0. Specifically, your util.h headers may never be loaded: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20348 For your current setup, I think it will work as long as you don't use an .xs file in the lib/... tree and expect that util.h will be loaded. To leave yourself with the possibility of doing that, however, I would suggest renaming util.[ch] to something unique. HTH John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: DateTime.pm on a Diet
Dave Rolsky wrote: It has a pretty different API, in that it's new() constructor accepts anything without validation. I suppose it could check for extra args and call DateTime::Fat-new() if needed. Can we split the existing new() into validation vs. object creation and share it between the two equally (no, I haven't looked at the source)? Thus, the lightweight new() could validate by default, but offer a quick no_validate = 1 option for the people creating objects out of databases (prevalidated). It may be once that you are slinging lightweight objects around most of the time, the performance drain due to validation won't be quite as noticible. I think that'd be a possibility, but it'd have to pass the DateTime.pm test suite in that case. That's certainly where I was considering starting (with the test suite). It might also be a good experiment to see where the performance issues really are. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: DateTime.pm on a Diet
Dave Rolsky wrote: It sounded like people were interested. And maybe it's a if you build it they will come thing ;) Anyway, go for it and let's brainstorm on a better namespace. Here's some thoughts: At the risk of sounding flippant, why not rename the existing DateTime class to DateTime::Fat (or the less inflamatory DateTime::Base) and put the proposed module in it's place as DateTime. If it is designed well, everything should Just Work(TM) with the shim class, which should always be faster than the existing class, even with the extra dispatch to plump up the object when needed. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Rethinking date math, time zones, etc for Perl 6 (and maybe DateTime2?)
Dave Rolsky wrote: - Work with just dates and do date math on them (at the level of days, months years). I think I was one of the ones advocating for a way to do this, since in a business environment, the time is frequently not important (for example number of days between order and shipment, or shipment and payment). I'd have to look back at the archives, but I believe I suggested either undef for the time values or internally setting the time to a fixed UTC time for all DT objects without time (like 12 noon, to stay away from any possible leap-day magic). It would require all math operations to be smarter, but I don't think it would require a completely redesigned API. For example, consider an object like this: year, month, day, hour, minute, second, TZ and at any point in that sequence, allow the user to set the value to undef (for I don't have any information about anything below this). All math operations would then stop at the point where either term (for binary operations) contained an undef (hence two disimilarly accurate DT objects would have a result no more accurate than the least accurate term). This would allow reduced precision date math to happen naturally. 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: DateTime marches on
Matt Sisk wrote: So I quickly made an update, and now HTML::CalendarMonth 1.11 is fully powered on the i8n back end by DateTime::Locale. And it works splendidly. That's funny! I noticed 1.10 on CPAN's Recent page, took a look at it and didn't download it, _because it didn't use DateTime_. Glad to see you came to your senses... ;-) John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Need help from Windows folks for Time::Local
Dave Rolsky wrote:
Could people with Windows run the following bit of Perl:
perl -le '@t = gmtime(-1); print grep {defined} @t ? [EMAIL PROTECTED] :
undef\n'
OK.
c:\perl -le '@t = gmtime(-1); print grep {defined} @t ? [EMAIL PROTECTED] :
undef\n'
Can't find string terminator ' anywhere before EOF at -e line 1.
;)
Sorry, I know that's not what you wanted to know:
c:\perl -le @t = gmtime(-1); print grep {defined} @t ? \[EMAIL PROTECTED] :
\undef\n\
undef
HTH
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: Activestate PPMs for DateTime?
Yitzchak Scott-Thoennes wrote: Module::Build already has it's own way to tell about dependencies but afaik no one uses it except CPANPLUS. And what is worse is that the Module::Build dependencies are treated as /suggestions/, and will not throw an error if one is not met. I just got a cpantester's report for one of my modules which only works with Perl 5.8.1 or better. Even though I added 'perl = 5.8.1' to the dependencies, Module::Build happily went on to try and build/test the module on a 5.6.1 machine. I actually have to add 'use 5.8.1' to the top of the Build.PL file to correctly bail out. :( 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: What is the current state of installing DateTime?
Ron Pero wrote: When finally attempting to install DateTime itself via nmake etc, I get multiple multiple failures. Could you be more specific? When attempting to install it via ppm, it fails with this message: Error installing package 'datetime': Read a PPD for 'datetime', but it is not in tended for this build of Perl (MSWin32-x86-multi-thread). That means that Activestate hasn't got a version of DateTime for Win32, but they do for some other platform (probably Linux). It's a really stupid error message. Most of the ppm's that Activestate maintains are done so automatically, so if there is any problem whatsoever, in any dependency, they don't always go back and see what was the problem. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Ambiguous years (what does 03 mean?)
Ben Bennett wrote: 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 Add the following code (modulo what you called the year variable): if (length($yr) 4) warn (Your year value is indeterminant. Performing SWAG[1]!); Then do a search on Google for y2k window and see how people suggested handling it. Yes, it _is_ completely bogus and arbitrary, why do you ask? But when dealing with malformed data, the old warhorse of GIGO[2] applies. John 1) http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=swagaction=Search 2) http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=gigoaction=Search -- 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: Ambiguous years (what does 03 mean?)
Eugene van der Pijll wrote: if (length($yr) 4) warn (Your year value is indeterminant. Performing SWAG[1]!); Why are years 1000 indeterminant? I was being [mostly] facetious. The format MM/DD/YY is very common, and mostly broken. The idea is that the end user needs to be hit with a high-voltage prod every time they use the common yet incomplete date format, in the hopes that they will eventually learn the lesson. One way to handle this (if the problem space is known) is to prompt for individual arguments for MONTH, DAY, CENTURY, and YEAR. In web forms, making the CENTURY be a dropdown list with 19, 20, 21, etc. will assist the user to no end in actually entering the proper information. 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: Ambiguous years (what does 03 mean?)
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: DateTime parse(), parser()
John Siracusa wrote: Great, but the $64K question is: do we then get parse() and parser() methods in DateTime, which default to use DT::F::Simple? :) A while ago, when this discussion last reared its [ugly] head, I suggested that the base class contain methods which would call an array of potentially more expensive parsers, until one returned a value other than undef. The default install would only include the smallest, fastest parser and the user could add other to the list. Thinking about it now, it would make the most sense to me to make DateTime::Format be an actual class which would dispatch to the DT::F::something modules. That way, nothing needs to be added to the DateTime class itself, if you never need parsing. 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: Natural Language DateTimes
Rick Measham wrote: In fact the only unsolvable I've had so far is with a phrase like It was twelve fifteen. This could mean it was the year 1215 or that it was a quarter past 12. Deciding which seems to be impossible! Except that I think, in colloquial English at least, no one refers to the year as twelve fifteen except verbally. I'll be very interested in seeing your module... John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [PLUG] Re: Slides from YAPC presentation
Joshua Hoblitt wrote: This question has crossed 3 lists that I'm on in various forms (datetime, pdx.pm, plug) and probably a few others. Maybe an out of town geek page would be a good idea? Add anything that you find missing here: http://oscon.kwiki.org/index.cgi?HomePage John (who saw this link on the P5P list) -- 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: Slides from YAPC presentation
Joshua Hoblitt wrote: Are you in town yet? I've instigated a pdx.pm GT either Tues. or Weds. of this week. Nope. I'll be getting in Saturday night (and probably wiped out until Sunday morning). I'm open to suggestions of what to do on Sunday, though I won't be getting a car unless provoked. I'm just starting to panic that I am not going to be able to survive with just a P233 notebook with a 56k modem when I am used to a 1.2GHz w/768k DSL. ;~) I've got a bunch of programming I want to accomplish next week and I don't want to be hampered by poor connectivity... Does anyone know if the Marriot's Rooms that Work includes a network connection? John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Slides from YAPC presentation
Joshua Hoblitt wrote: I'm actually from Portland and arriving on the 27th of June if anyone wants to get together before/during/after OSCON. I'm getting in July 5 and not leaving until the 12th (cheaper fares, don't you know ;). I wonder if it would be worthwhile to try and get a BOF together for http://www.lxgmovie.com/ which opens Friday night? Is there a decent movie theatre downtown? John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Getting different results from DateTime and Manip for epoch time
Peter J. Acklam wrote: Iain Truskett [EMAIL PROTECTED] wrote: Unix epochs are always GMT/UTC based (one of the two). Perl's gmtime() and localtime() aren't UTC compatible. I'd say they are using TAI time. GMT belongs to the past. Except you'd be wrong. ;~) GMT == UTC for all intents and purposes: http://www.wikipedia.org/wiki/Coordinated_Universal_Time http://www.webreference.com/js/tips/010929.html Perl is not using TAI, but rather the underlying O/S epoch (which usually means UTC). There is some discussion of using Dan Bernstein's libtai as a basis for time values in Perl6, but I don't think that has been settled yet. 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: Getting different results from DateTime and Manip for epoch time
Peter J. Acklam wrote:
Conveniently for me, the pages you quote back me up, not you.
I should have been more explicit in what I was asserting, then. The colloquial
term GMT has been supplanted by the functionally equivalent, and much more
accurately defined, UTC as the source of international time. Since 1986 at
least, anyone referring to GMT was actually talking about UTC, i.e. EST is UTC-4
_not_ GMT-4. GMT was always a social convention, and as such, people still use
it in the colloquial sense. UTC is an international standard, based on precise
rules and measurements, which is nonetheless employed in exactly the same
situations as formerly covered by GMT.
I have no argument that the definition of UTC is completely different from the
loosely defined GMT. However, it is clear that GMT lead directly to UTC (which
is why the Zulu timezone is still Greenwich. And it is also clear that when
most people today refer to GMT, they are actually talking about UTC. Only us
time weenies (and astronomers) care about the details...
Perl is not using TAI, but rather the underlying O/S epoch
(which usually means UTC).
I didn't mean that Perl is using a TAI library, but the TAI time
system or TAI calendar. The reason why I suggested TAI was that
in the TAI time system there are no leap seconds and every second
has the same length. GMT doesn't have leap seconds either, but
the length of each second is not a fixed value.
Perl is _not_ using TAI, since it is employing an epoch corresponding to the
Unix epoch (except on Mac's???). It is, however, not correctly handling
leapseconds, which isn't too suprising since hardly anything does. NTP, for
example, does not handle leapseconds either.
See this discussion by Dr. Bernstein:
http://cr.yp.to/proto/utctai.html
In it, he suggests that some O/S vendors have correctly patched localtime() to
use the Olson library (in strict violation of POSIX specs). At least on the
*nix's I have here, I see no sign of leap seconds:
$ cat test.c
#include stdio.h
#include time.h
int main(void)
{
time_t result;
for ( result = 78796799; result =78796801; result++)
{
printf(%s, asctime(gmtime(result)));
}
return(0);
}
yields
$ ./test
Fri Jun 30 23:59:59 1972
Sat Jul 1 00:00:00 1972
Sat Jul 1 00:00:01 1972
which is the same output as Perl.
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: Win32 failures in t/20infinite.t
Dave Rolsky wrote: Ok, I applied this. Does this mean all tests pass on Win32 now? I don't know; I'm at home (Linux only, thanks) and not at work. I'll get the latest CVS and double check on Monday. Is that soon enough? John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
DateTime 0.12CVS - Success from Cygwin, still failing under VC++
The t/13strftime.t file has DOS line endings, which causes all tests to fail
under Cygwin. If that is corrected, then Cygwin tests completely clean.
However, I am still seeing the following failures with Win32/VC++:
t\04epoch.t 255 65280283 10.71% 26-28
t\20infinite.t3 768363 8.33% 12-14
even after installing the updated Time::Local from CPAN.
Specifically, the first failure is this block:
{
my $dt = DateTime-from_epoch( epoch = -2082844800 ); #fails here
is( $dt-year, 1904, 'year should be 1904' );
is( $dt-month, 1, 'month should be 1904' );
is( $dt-day, 1, 'day should be 1904' );
}
which fails because this code in from_epoch():
@args{ qw( second minute hour day month year ) } =
( gmtime( delete $p{epoch} ) )[ 0..5 ];
does not, in fact initialize anything in the %args hash:
%args = (
month = undef,
day = undef,
minute = undef,
year = undef,
hour = undef,
second = undef
);
Apparently M$loth's implementation of gmtime() doesn't support negative numbers
_at all_:
D:\working\DateTime-0.12perl -e print ''.scalar gmtime(1).''
Thu Jan 1 00:00:01 1970
D:\working\DateTime-0.12perl -e print ''.scalar gmtime(-1).''
even though time_t is defined as a long integer (not unsigned long):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt_mktime.asp
MORONS!
Anyone up to creating a POSIX compliant gmtime() out of whole cloth for the poor
souls running Win32??? I guess that could be included in Time::Local...
I'll move on to the t\20infinite.t failures next.
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: DateTime 0.12CVS - Success from Cygwin, still failing under V C++
Hill, Ronald wrote: fails horrably on windows :( I posted this on CLPM maybe someone has something on this. It's even documented that way now in bleadperl: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00495.html :~( 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: DateTime 0.12CVS - Success from Cygwin, still failing under VC++
John Peacock wrote: Hill, Ronald wrote: fails horrably on windows :( I posted this on CLPM maybe someone has something on this. It's even documented that way now in bleadperl: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00495.html And to follow up on that, it appears that POSIX used the C definition for gmtime() and it does not *explicitely* require support for negative time_t values. It appears that DEC implementated negative time_t support and other vendors added it as well (AIX 3.2.5 has it for example). Dopes! If you aren't going to support negative numbers, why use long integer (and give rise to the Y2038 issue)? 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: installing DateTime-TimeZone-0.17 on HPUX 10.20... or Cygwin
Hill, Ronald wrote: I was not able to get this to work with the HP make utility However, I installed gmake and it works!!! I was able to install the DateTime-TimeZone-0.17. Where do we document these kinda things? Rather than document it, is there any way to fix the Makefile to have 32 1k lines instead of 1 32k line? Having to require a specific make/gmake is really not a good plan. It should be very unusual to require some different helper utility like 'gmake' to build an extension to Perl when that resident 'make' can build Perl itself. 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: DateTime Development Standards - Another Suggestion?
Dave Rolsky wrote: Rationale: CVS generates revision numbers that are not actually floating point numbers. The Perl module tools like CPAN.pm do not understand that these numbers are not real floating point, causing problems for users of these tools. I've been working at fixing this 'misfeature', see http://search.cpan.org/author/JPEACOCK/version-0.28/ I've currently got this into the core of 5.9.0 (and unless it is removed it will be in 5.10). This module can be used as far back as 5.005_03 (though it does require XS). I believe there was some interest in using my version model in CPANPLUS, so this prohibition may be waning. And of course, there are ways around it, too: $VERSION = sprintf(%d.%02d,split(/\./,(qw$Revision: 1.9 $)[1])); (it's not pretty, but it will work as long as you don't branch). My module supports the much more readable: use version; $VERSION = new version qw$Revision: 1.9 $; which sadly doesn't help me that much since I am moving to Subversion myself... HTH John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: DateTime Development Standards - Another Suggestion?
Dave Rolsky wrote: That only works for the first 99 revisions. Several of the modules in the Mason repository are at over 200 revisions!. Then use %d.%03d or increment the major version occasionally! My module will handle an unlimited amount of subversions, though the numify() operator assumes 999 subversions (and it handles branches just fine). John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: DateTime-Set.pm
Dave Rolsky wrote: truncate( to='month' ) is setting the month to 1. I think it should only do that if I asked to truncate to 'year', isn't it? Or maybe I'm doing something wrong. I guess this depends on your expectations. What do others think? Does truncating to the month include the month or not? I think that the truncation should be the highest granularity _preserved_, i.e. 'month' should drop the days and time, and truncate(to='year') should drop everything except the year. 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: date math and local times
Peter J. Acklam wrote: You run into essentially the same problems when dealing with leap seconds -- which any software using UTC should be able to handle. For instance, what is one day after 1998-12-31 25:59:60 UTC? Is it 1999-01-01 25:59:59 UTC or 1999-01-02 00:00:00 UTC? I think you mean 1998-12-31 23:59:60 UTC, since there isn't a leap hour yet (until the moon rockets out of orbit in 1999, anyways ;~)... I would argue that the correct answer should be 1999-01-02 00:00:00 UTC. Add the requested period and then normalize if appropriate. 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: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
Dave Rolsky wrote: It seems rather arbitrary to only include Chicago and New York. I can just see all the questions about why the others aren't included! That's just the TZ's you tested, that's all. Any arbitrary bias lies in the scope of the tests, not in my suggestion! duck It might be best to just skip those tests if the DateTime::TimeZone package isn't installed, though. This is a better idea. Or distribute everything _but_ the generated files and DateTime::TimeZone::OlsonDB. That way you could do offset only and floating time zone stuff, but to do the historical/rules-based stuff you install a separate package. This is the best idea of all. How about DateTime::TimeZone contains logic to die with a useful message when a missing TZ is requested, rather than allow Perl's default error to come up and confuse the user. file (if you want to make the installation dependent on Net::FTP). For those that don't have Net::FTP installed, the Makefile.PL could request that they independently download the Olson files themselves and expand them into a top level OlsonDB directory and rerun 'perl Makefile.PL' to build the TZ files. Now that's a PITA! It depends on Net::FTP _and_ Archive::Zip (the TZ data is in a zip file). Too much work for now at least. Granted, but we want people to be able to easily download an updated OlsonDB and regenerate all of the TZ files. I don't suppose you want to keep releasing updates to DT::TZ _every_ time the OlsonDB gets updated. ;~) The idea is empower the user to update their own d**n data files and keep the CPAN distro as small/simple as possible. 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: DateTime::TimeZone 0.01_00
Dave Rolsky wrote:
Please try them out and let me know what you think, what bugs you find,
etc.
I don't think it is really necessary to manify all of the various
TimeZone/*/*.pm data files; there is no real point in doing so (since there is
no substantive information for the user contained within). I view
ExtUtils::MakeMaker's obsessive creation of man files for every .PM file to be
an undesireable feature, just shy of an outright bug.
I would suggest something like the attached which will manify only the files
with some content. perldoc will still be able to display the POD for the data
files, if desired.
John
p.s. You also need to apply the following minor patch
--- t/01load.t.orig 2003-02-04 22:49:35.0 -0500
+++ t/01load.t 2003-02-04 22:49:48.0 -0500
@@ -14,7 +14,4 @@ BEGIN
plan tests = 1;
-BEGIN
-{
-use_ok('DateTime::TimeZone');
-}
+use_ok('DateTime::TimeZone');
since you cannot have the use_ok() wrapped in a BEGIN (since Test::More won't be
loaded yet).
--
John Peacock
Director of Information Research and Technology
Rowman Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
--- Makefile.PL.orig2003-02-04 22:36:40.0 -0500
+++ Makefile.PL 2003-02-04 22:38:43.0 -0500
@@ -6,6 +6,16 @@ WriteMakefile( NAME = 'DateTime
VERSION_FROM = 'lib/DateTime/TimeZone.pm',
AUTHOR = 'Dave Rolsky [EMAIL PROTECTED]',
ABSTRACT = '',
+ MAN3PODS = {
+ 'lib/DateTime/TimeZone.pm'
+ = '$(INST_MAN3DIR)/DateTime::TimeZone.$(MAN3EXT)',
+ 'lib/DateTime/TimeZoneCatalog.pm'
+ = '$(INST_MAN3DIR)/DateTime::TimeZoneCatalog.$(MAN3EXT)',
+ 'lib/DateTime/TimeZone/OffsetOnly.pm'
+ = '$(INST_MAN3DIR)/DateTime::TimeZone::OffsetOnly.$(MAN3EXT)',
+ 'lib/DateTime/TimeZone/UTC.pm'
+ = '$(INST_MAN3DIR)/DateTime::TimeZone::UTC.$(MAN3EXT)',
+ },
PREREQ_PM = { 'Tree::RedBlack' = 0,
'Params::Validate' = 0,
'Class::Singleton' = 1.03,
Re: Working time zone code!
Dave Rolsky wrote: I should probably just check in the generated files and be done with it. Anyone have any objections to that? Certainly to start with. Perhaps we can detangle the modules so that a reduced functionality for DateTime is available without having to require DateTime::TimeZone... John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Changing time zones?
Dave Rolsky wrote: The other would be to change the local time (in effect shifting the UTC time). Store in UTC (always). If they shift the rug underneath the object, apply the net offset to the UTC time and store the new TZ. Think of it this way: my $buffy = new ...; # Washington, DC @ 8pm $dt-set( time_zone = 'America/Denver' ); # Boulder, CO @ 6pm It's an operation, not just a flag. IMNSHO ;~) John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Working time zone code!
Dave Rolsky wrote: I just checked in a lot of new/changed code under modules/DateTime-TimeZone. This code actually seems to work, and provides access to the complete Olson historical data, plus ongoing time zone changes in the future. t/01load.NOK 1# Failed test (t/01load.t at line 7) # Tried to use 'DateTime::TimeZone'. # Error: Can't locate DateTime/TimeZoneCatalog.pm in @INC Did you forget to add this file to the CVS repository??? John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Grand Unified Theory of Date/Time modules
Dave Rolsky wrote: Well, an XS implementation is quite likely to beat pure Perl, even if you used RD days as well. Don't tell anyone, but my first pass will be pure Perl, since I am still pretty much an XS newbie... John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Grand Unified Theory of Date/Time modules
Dave Rolsky wrote: Hehe, that's fine. My guess is that this is probably a much easier way to write an XS module, since all you'll have to do is re-implement the same logic in C, which leaves you free to _only_ think about all the low-level C crap you have to deal with, as opposed to trying to think about low and high level concerns at the same time. Hey! I thought you were doing all of the high level thinking here! duck John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Grand Unified Theory of Date/Time modules
Dave Rolsky wrote: You'll probably need to write your own module around DateTime.pm. For example, how do you handle adding 3 days to july 1974? How about 31 days? I think that we should treat this as 3 + undef, since the date in question did not specify a day, only a month. So I would either return july 1974 (plus a warning) or throw an error (Date does not have enough precision). This leads me nicely into what I've been thinking about. There was a discussion on this list about temporal granularity back in May 2001: http:[EMAIL PROTECTED]/msg00045.html which was mostly part of the original What's our Name Space??? discussion. However, I find the concept itself very appealing for the present discussion of storage methods. For example, if a geologist wants to use a DateTime object, he is only interested in years (and millions of them) and not what time it was (apologies to Bishop Usher). Similarly, someone writing a business calendar (how many days until I get paid for this job) is not going to care about attoseconds. Someone writing a realtime event program may only want to know how many seconds have elapsed since some previous time. Each user will have a different granularity of interest. Hence, it would seem to me to make the most sense to store the basic DateTime object as an array of (possibly undefined) periods: years, months, days, hours, minutes, seconds, etc. By doing it this way, instead of some sort of days since some epoch, any date or in fact any time differences are trivial. And by storing the data in an array from most to least significant values, it would be possible to ignore meaningless distinctions where appropriate. I hear the gnashing of teeth out there already: But what about leap seconds? and What about different TZ calculations? This doesn't preclude handling those appropriately, when called for. If someone cares about how many seconds there are between two DateTime objects, and both objects are defined with seconds, then both the TZ and leap seconds come into play. If only one object has seconds, my gut says give an answer with a supressable warning that accuracy has been lost; if neither are precise enough, die screaming. On the other hand, if someone wants to know how many months there were between May, 1776 and June, 1976, it seems less than helpful to convert to Rata Die or seconds (or heavens be, attoseconds ;~) to store the data, then subtracting and finally dividing repeatedly, just to get the answer 200*12 + 1. Sure, there are lots of useful formulas to go from Rata Die to other date formats; store that too, as a cached value. Or just convert to that when going to other formats (my preferred method). Those are going to be the exceptional cases. The general case is someone who wants to calculate hours between something, days until my birthday, years since Lincoln died. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Parser/Backend API proposals
Dave Rolsky wrote:
I should also point out I'm moving the ical-specific bits to
DateTime::Formats::ICal.
As soon as SF gets their servers back in operation (what's up with that?), I'll
take a look at what you have. My quicky module is not meant to be an example of
anything practical, just something to toy with. In particular, you (in
particular) will blanche at the fact I used Autoloader (since that is what
h2xs normally includes), which is not friendly towards mod_perl code.
How about this instead:
my $formatter =
DateTime::Formats::ISO8601-new
( class = 'DateTime::Implementation::TAI64' );
my $dt = $formatter-parse( ... );
That's OK, but too verbose for the average user, IMHO. It also leaps too deeply
into the API for my taste. I would suggest that the average user shouldn't need
to do anything more than
my $dt = DateTime-new($datestring);
and have that do something useful for the majority of the trivial cases. I hate
to keep bringing up Math::BigInt, but the model is very close to what I think is
ideal. The base package works out of the box, but if you want better
performance, you add one line and your existing code works just the same, only
faster:
use Math::BigInt; # implicitly uses Math::BigInt::Calc
use Math::BigInt lib = 'BitVect'; # faster backend
and there is no need to change your existing code; I think it unlikely that
anyone would want to use more than one storage/backend module at the same time.
I also think I didn't explain my proposal sufficiently. I would argue that the
parser modules should be extremely thin and not full fledged constructors. All
that the parser would do is parse into a common format and leave the object
creation to the storage module.
The assumption here is that there is a standard set of arguments which can
be given to the constructor, which follows from the assumption that all
DateTime core object implementations share an API. These constructor
arguments would probably be:
year, month, day
hour, minute, second
time_zone
which is exactly my $obj-as_array method would return. The reason that I
suggested multiple possible parses is that some backends (like TAI) already have
a conversion from a specific external representation to their internal
representation. If the array of arguments is agreed to be the most likely
normalized representation, I would actually have the Formats modules include
only a single function Parse() which would return the normalized relationship
(or undef if this parser cannot handle that date string).
I think we should assume that creating a format/parse object will be
one step, and actual parsing/formatting will be a different one.
Why? It requires the average user to know far more about the internals than is
strictly necessary. Sure, it has to be available for those who need it, but it
shouldn't be the default interface.
I don't think the parser should be directly responsible for producing
anything other than DateTime.pm API-compliant object, which may or may
not actually _be_ a DateTime.pm object.
Well then we may be saying the same thing; I want the parser to generate a
normalized date format. I'm just saying that making the parser itself an object
is not _required_ to do that.
So what's implemented in DateTime.pm in this idea? Nothing? If nothing,
it might as well just return an object in a different class. I don't
think I understand what you're suggesting.
Not at all. DateTime is the gatekeeper class; it contains any overloading code
(which you haven't really mentioned yet, have you?) as well as all of the
exposed API. But it doesn't need to contain the actual code to implement the
API, and I would argue, shouldn't. See below
I have DateTime::Formats::ISO8601 done (well formed ISO dates only); I attach it
for your pleasure. I can work on DateTime::Formats::Date_Parse for the more
By Date_Parse do you mean complex Date::Manip style parsing?
No, actually I meant Graham Barr's Date::Parse (part of Time::Date). Someone
will likely want the Date::Manip parsing available as well.
As to DateTime::Thingy::TAI64, I think it needs to do the following:
- implement the same API as DateTime.pm, possibly adding some TAI64
methods if that's useful
- inherit from DateTime.pm - this follows from the former. There's no
reason to implement a method like year_0, which is defined in
DateTime.pm as:
sub year_0 { $_[0]-year - 1 }
There's a number of other methods in DateTime.pm it'd be pointless to
override as well, along these same lines.
No question. Any implemention class will inherit all of the derivable methods
and only implement/override the minority of primitive methods (like $obj-year
for example).
John
--
John Peacock
Director of Information Research and Technology
Rowman Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
Re: Calendrical Calculations and licensing
Abigail wrote: I don't think you quoted the part where they put a restriction on the algorithms (which, AFAIK, are not copyrightable or patentable; they fall in the same categories as ideas, which can't be copyrighted either). Ummm, at least in the US, algorythms _can_ be patented. See GIF patent: http://www.delphion.com/details?pn=US04558302__ and Shure has a patent for DSP: http://www.shure.com/news/pressreleases/pr-dsppatent.html and finally this extract: under U.S. patent law a mathematical algorithm is not patentable if the patent claim preempts the entire algorithm, but may be patentable if it applies the algorithm to accomplish a specific technical purpose. All of these patents may be bogus and could be overturned by a court; nonetheless, it is technically legal to patent algorithms under some circumstances in the U.S. Other countries vary... John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Parser Interface (Was Re: Picking up the ball)
Dave Rolsky wrote: use DateTime; use DateTime::Parse::MySQL; my $dt = DateTime::Parse::MySQL-new_datetime( $mysql_dt ); print DateTime::Parse::MySQL-mysql_datetime( $dt ); I can also imagine some other scheme, where parse/format modules register the formats they can handle with DateTime.pm. But I'm very strongly opposed to something that just passes random strings into new() and then loads the module on demand. I guess that is the part that I don't understand. If you have the ability to add new parsing methodology to a list, you can just as easily subtract. So, if you want to use only the basic parsing and throw an error if you get a non-standard date format: use DateTime ( parse = basic); # class-wide default my $date1 = DateTime-new($dtstring); # better be ISO CCYYMMDD my $sqldate = DateTime-new($sqlstr, parse = MySQL); # object override etc. This is a much more friendly interface for the average programmer. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Picking up the ball
Dave Rolsky wrote: I don't know why, but it's time to change it. Good for you! Count me in somewhere between moral support and actually dedicating myself to coding. ;~) No, seriously, I cannot promise any specific level of support, but I will be very interested in the API discussion. And that is where we should spend all of our time, IMHO. 1. Stop herding cats. If existing module authors don't want to play, then screw them. One word for you: wrappers. I want to call to your attention the methodology pursued by Tels when he rewrote the Math::BigInt/BigFloat core modules. He identified (with my careful prodding) the minimal subset of operations required as the backend and extracted that from the main code. Then he wrote (without my help at all ;~) interface layers to various extended precision math modules, hence: Math::BigInt::Calc - pure Perl, comes with M::BI Math::BigInt::FastCalc - XS implementation of above Math::BigInt::Pari - uses Math::Pari = PARI library Math::BigInt::BitVect - uses Bit::Vector Math::BigInt::GMP - XS using GMP library etc. The interface is all important here, but it should be too difficult to come up with the universe of operations we want to operate with. The basic ops that overloading supports, plus a very few is probably sufficient. 2. Use the DateTime:: namespace. If you use it, they will come... 3. Start with set of base data objects around which functionality can be built. - DateTime::Object I have to agree with the others that the base class should be DateTime itself, with, as I suggested above, a set of modules to support the actual operations, which themselves could be replaced by other interpretations/implementations. One issue I see is that the DateTime:: namespace will likely contain both implementation classes, e.g. DateTime::Parse, as well as subclasses, e.g. DateTime::Discordian. This will make the strict OO people crazy, but it is certain the Perl Way. snip some good example classes I'll display my bias here: I am developing in a corporate environment where the time variable is frequently completely unimportant and the only interesting issue is dates. I care about days between, or adding days, or business days or whatever. I think any system that will be good for me will permit me to completely supress the time aspect without requiring me to think about it. For example: use DateTime qw(NoTime); my $order_dt = new DateTime today; # 2003/01/10 my $ship_dt = $order_dt + 5;# 2003/01/15 etc. I don't care whether the underlying implementation is TAI64 or Date::Calc, just as long as I can say Don't care about attoseconds! to the code and have it DWIM. Good luck! John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Date::Calc week number calculation
John Peacock wrote: since the first Thusday in January is Jan 2, 2003, that is Week 1 (and hence Date::Calc is wrong). Note also the last line of that answer (that this numbering is not used in the US). Sorry, I read your description the wrong way round; Date::Calc is correct (sorry Steffen!) and your _vendor_ is wrong. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Proposed CPAN submission - Time::RateLimit
Jay Soffian wrote:
SYNOPSIS
use Time::RateLimit ':all';
calibrate();# takes a second or two to complete
You could certainly put calibrate() inside a BEGIN{} block in your module so
that it will run when loading. Obviously in this case, don't export that sub;
this will also deal with namespace polution complaints.
John
--
John Peacock
Director of Information Research and Technology
Rowman Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
