Re: Alternative strftime
On Wed, Jan 15, 2003 at 12:25:34AM +0200, Antonios Christofides wrote: David Wheeler wrote: It also means that users have to memorize all of the arcane strftime formatting characters. I don't know them all, and I use stftime all the time. This is because strftime's format specifiers suck. And since the module is brand new with a brand new interface, aiming to get rid of old sucky things, why don't we get rid of strftime? Believe it or not there are some people in the world that *like* strftime() :-) I don't see why we can't have a strftime() formatter. People are used to it and there are gobs of code that use it. Besides, if we come up with a like-strftime-but-better formatter and start using it, eventually people will see its merits and choose it over the strftime formatter. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: The first day of the week is ...
On Tuesday, January 14, 2003, at 02:24 PM, Antonios Christofides wrote: Dave Rolsky wrote: Monday! How exciting. I figured I might as well just pick something, and so I picked Monday. There were a lot of excellent candidates, and Friday's performance was excellent, but overall Monday best exemplified the qualities that I look for in a week-starter. (rofl) No objection, and no buts. But :-) since the discussion is getting real fun with all those Romans, Mayas, Chinese, and so on, I think I'll go on. [snip of interesting info about Greek/Christian origins of English/European day names] Aren't you going to do the same? (I'm just asking.) Isn't weekend the week end? Don't you feel that a cycle begins on the first working day of the week? The bottom line: Surely people all over the world do begin their diet on Mondays? I come at the first day of the week issue somewhat differently: my applications produce the many bits of information needed for creating visual calendars, i.e., for print, HTML, and other visual formats for human use. So for a given date I have to calculate a start-of-week for the visual layout as well as the appropriate start-of-week based on work-week, sacred tradition, tide-chart (for many here in Santa Cruz the cultural definition of 'work week' depends on surf conditions...), etc. In the U.S., most printed calendar _layouts_ have weeks starting with Sunday. Sun Mon Tue Wed Thu Fri Sat Because I've done some calendars that _don't_ have the typical (U.S) Sun-Sat week layout, my calendar-generating module is agnostic with respect to start-of-week, although it defaults to Sun-Sat weeks for convenience. The main thing is that it has to know what day-of-week *number* to use when setting its layout-start-of-week *day*. That's why I don't need the day-of-week number to be a 0-based index -- that just assumes that I want the zero-indexed value for the first day. Dave has announced that Monday has day-of-week number 1. That's all I need to know. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Copyright on algorithms in FAQ (fwd)
Just as an FYI for all datetime implementors. -- Forwarded message -- Date: 15 Jan 2003 21:56:36 +0100 From: Claus Tondering [EMAIL PROTECTED] To: Dave Rolsky [EMAIL PROTECTED] Subject: Re: Copyright on algorithms in FAQ Hi Dave, You wrote: So we need to know if you're asserting a copyright on the _algorithms themselves_, Absolutely not. I find it quite silly to assert copyright on an algorithm. The next thing we know, somebody will be copyrighting the fomula 2+2=4. Please feel free to implement the algorithms any way you like! Best wishes, Claus Tondering, Lyngby, Denmark E-mail: [EMAIL PROTECTED]
Re: Calendrical Calculations and licensing
On Wed, Jan 15, 2003 at 02:43:57PM -0600, Dave Rolsky wrote: Because of this, I think we need to take the following steps: 1. No implementation should explicitly use algorithms from CC. 2. No discussion of implementation matters should refer to Calendrical Calculations. For example, don't tell someone else go read chapter X. Because if they read chapter X and then implement it, they can't distribute it. I agree, but you forgot step 0: Ask the authors if they'd be willing to release the code under an open source license. It doesn't hurt to ask and if they refuse, then we just continue ignoring the book for implementation advice. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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: Calendrical Calculations and licensing
On Wed, 15 Jan 2003, srl wrote: Rich Bowen emailed them at one point and got an agreement from them that he could implement the algorithms and release the code freely, as long as he let them publish the code in the next version of the book. Last I heard, he was confirming that understanding with them. Oh yeah, he did say that, didn't he? If that could be extended from Rich to anyone working on the Perl DateTime project, then we'd be all set. Though I still think that either their license should be reworded (cause it doesn't reflect their intent) or their intent is _evil_ (if the license really means what I think it means). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Calendrical Calculations and licensing
On Wed, 15 Jan 2003, Jonathan Scott Duff wrote: I agree, but you forgot step 0: Ask the authors if they'd be willing to release the code under an open source license. It doesn't hurt to ask and if they refuse, then we just continue ignoring the book for implementation advice. I did mention that, actually. Rich is already working on it, as Shane pointed out. But 1 2 need to be in effect until we have that permission, not after its denied. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Calendrical Calculations and licensing
On Wed, 15 Jan 2003, Dave Rolsky wrote: On Wed, 15 Jan 2003, srl wrote: Rich Bowen emailed them at one point and got an agreement from them that he could implement the algorithms and release the code freely, as long as he let them publish the code in the next version of the book. Last I heard, he was confirming that understanding with them. Oh yeah, he did say that, didn't he? If that could be extended from Rich to anyone working on the Perl DateTime project, then we'd be all set. Though I still think that either their license should be reworded (cause it doesn't reflect their intent) or their intent is _evil_ (if the license really means what I think it means). I've not yet received a response from RD about this. I will send another note. -- Nothing is perfekt. Certainly not me. Success to failure. Just a matter of degrees.
Re: Parsing/Formatting API
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote: OK, that'll let us parse a Discordian date and format it as a Gregorian; I assume that to print something in Discordian format we'd use: my $disc = DateTime::Calendar::Discordian-new( object = $dt ); print $disc-strftime( ... ) I'm concerned that this approach may end up requiring that DateTime::Calendar::Discordian to be a subclass of DateTime, and I know you've recently argued that calendars that aren't Gregorian shouldn't be subclasses of DateTime due to API confusion issues. You seem to be assuming that other calendars are likely to be able to take advantage of DateTime.pm methods like strftime() or hour(). I am assuming that this won't be the case. But I'm not a calendar author. Rich, Abigail, Jean? What do you think. Because I took Mordechai Abzug's API, I wrote a date_string method. I just added an optional parameter: a string containing such things as %y, %d etc. So, my enhanced date_string method actually *is* strftime with another name. I could do this because the French_Rev calendar has concepts that are similar to the Gregorian calendar it was meant to replace. So, instead of a week number we have a décade number, instead of a day of week (Mon, Tue...) we have a day of décade (Pri, Duo...). But a Discordian and a Mayan would tell you different things... By the way, answering another of your messages: Who needs %E* and %O* modifiers? I need them. The traditional way to write a FR year is to use Roman numerals. So, while %Y gives you the Indian-Arabian numerals (2003), %EY gives you the Roman numerals (MMIII). At the same time, while %j gives you the 1..366 number of a day, %Ej gives you the designation of the day (which was meant to replace the saint of the day). Example, from my .profile: print $day-date_string(Today is %A %d %B %EY, %Ej%n); gave me a few minutes ago: Today is Sextidi 26 Nivôse CCXI, jour de l'étain Jean -- WYGIWYGAINGW = What You Get Is What You're Given And It's No Good Whining. Archichancelier Mustrum Ridcully (cité par Terry Prachett dans The Science of Discworld)
Re: DateTime::Set API
On Wed, Jan 15, 2003 at 03:34:32PM -0600, Dave Rolsky wrote:
Another side note on recurrence: we will allow people to specify
recurring datetime generators via callbacks. For what I hope are obvious
reasons, callbacks will have to guarantee that given a datetime X, they
always produce a datetime X _or_ X. If it were both, there'd be no way
to check whether Y was a member of an unbounded set. This will be a big
fat warning in the docs.
Or you could specify that all generated times that are beyond the
bounds are mapped to the appropriate endpoint. Still, caveat
scriptor.
Come again? I don't undestand what you're suggesting
Oh, I guess I was misunderstanding you. After reading again, I think
you're saying that the generators should generate strictly increasing or
strictly decreasing datetimes.
The callbacks will work like this:
sub generate_each_saturday
{
my $dt = shift; # highest date current known to be in set
Here's the part I was having trouble with ... why the highest date?
But I guess the directionality of the generator determines what gets
passed to the generator? If it's generating backwards in time it
would be given the lowest date?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Parsing/Formatting API
On Tue, 14 Jan 2003, Dave Rolsky wrote:
2. I really want to avoid runtime module loading. This is because I have
a mod_perl bias, and with mod_perl, it's much better to load modules at
compile time (in the parent Apache process) than at runtime, where the
module ends up being loaded once per child process. See
http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modules_at_Server_Startup
for an explanation of why this is important.
This doesn't necessarily rule out the -new( MySQL = $sqldate ) syntax,
though, as long as we provide a way to preload the necessary parser
modules. The simplest way would probably be this:
use DateTime;
#use DateTime::Parse::MySQL; # mod_perl users uncomment this!
my $dt = DateTime-new( MySQL = $sqldate );
a. I like named parameters for any method that is likely to ever take
more than one parameter.
Assuming that the parser itself needs to take more than one parameter,
those could always be wrapped in a hashref or an arrayref:
my $dt = DateTime-new( Discordian = { year = 3169,
season = 'Chaos',
day= 16 },
Extra = 'something not for the parser' );
(But is there actually a reason why we couldn't pass all the parameters
to the parser anyway?)
b. It's way too magical and could cause very weird effects. A simply
typo could cause the extended parsing to be loaded, which would be
very surprising for end users.
I don't quite get this. Are you talking about something else? Such as
format guessing? (Which would be doomed to fail anyway.)
c. It would require DateTime.pm to know about all possible parsing
extensions. (Ok, a registration scheme could get around this)
No it wouldn't. Just have it require() the extension on demand. As I
said, mod_perl users can always pre-load all the extensions they'll use.
There _are_ times when symrefs (well, dynamic package names, in this
case) are appropriate. I'd say this is one of them.
Heck, even if we eliminated the dynamic loading, and made the preloading
mandatory, this would still be cleaner than what you'd suggested.
4. Given the choice between adding more parameters or more methods, I
prefer to add more methods, which is why I dislike
DateTime-new( mysql = $mysql_dt )
as opposed to
DateTime-from_mysql_datetime( $mysql_dt )
Hmm. We appear to disagree on that principle. I do think there are
circumstances where adding methods may simplify the interface, but I
don't think this is one of them.
In particular, I dislike your suggestion because those extra methods end
up polluting the DateTime:: namespace. I don't like namespace pollution
at all -- if I wanted method names like from_mysql_datetime(), I'd write
my scripts in PHP.
Hopefully the above guidelines explain why I've been so vehemently opposed
to some proposals so far. There really is a guiding set of principles at
work here, I'm not just flipping coins.
They do explain your position admirably. It's just that it seems to me
that you've overlooked certain issues here (such as the simple solution
to the mod_perl issues that I've described above).
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
... programs that work in spite of themselves are not what should be
guiding language design. -- Sean M. Burke on the perl5-porters list
Re: Parsing/Formatting API
On Thu, 16 Jan 2003, Ilmari Karonen wrote:
module ends up being loaded once per child process. See
http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modules_at_Server_Startup
for an explanation of why this is important.
This doesn't necessarily rule out the -new( MySQL = $sqldate ) syntax,
though, as long as we provide a way to preload the necessary parser
modules. The simplest way would probably be this:
use DateTime;
#use DateTime::Parse::MySQL; # mod_perl users uncomment this!
Yes, I know. I was just responding to people's suggestions that things be
loaded on demand.
a. I like named parameters for any method that is likely to ever take
more than one parameter.
Assuming that the parser itself needs to take more than one parameter,
those could always be wrapped in a hashref or an arrayref:
my $dt = DateTime-new( Discordian = { year = 3169,
season = 'Chaos',
day= 16 },
Extra = 'something not for the parser' );
Sure, that'd work, although your above example confuses two things,
parsing and non-Gregorian calendars. To create a Gregorian date from a
Discordian date, you'd do:
my $disco = DateTime::Calendar::Discordian-new( year = 3169,
season = 'Chaos',
day = 16 );
my $dt = DateTime-new( object = $disco );
(But is there actually a reason why we couldn't pass all the parameters
to the parser anyway?)
I'd prefer not to, because its hard to distinguish between passing extra
parameters intentionally and passing extra parameters as a mistake. I'm
thinking of using Params::Validate for parameter validation and it
intentionally disallows extra parameters (at least by default).
b. It's way too magical and could cause very weird effects. A simply
typo could cause the extended parsing to be loaded, which would be
very surprising for end users.
I don't quite get this. Are you talking about something else? Such as
format guessing? (Which would be doomed to fail anyway.)
Someone was indeed suggesting format guessing, yes. Not me.
c. It would require DateTime.pm to know about all possible parsing
extensions. (Ok, a registration scheme could get around this)
No it wouldn't. Just have it require() the extension on demand. As I
said, mod_perl users can always pre-load all the extensions they'll use.
There _are_ times when symrefs (well, dynamic package names, in this
case) are appropriate. I'd say this is one of them.
Heck, even if we eliminated the dynamic loading, and made the preloading
mandatory, this would still be cleaner than what you'd suggested.
I've made at least two different suggestions. You're only responding to
one of them!
In particular, I dislike your suggestion because those extra methods end
up polluting the DateTime:: namespace. I don't like namespace pollution
at all -- if I wanted method names like from_mysql_datetime(), I'd write
my scripts in PHP.
Fine, no extra methods. In that case, I prefer to do parsing explicitly,
ala:
my $dt = DateTime::Parse::Extended-parse( the 3rd Sunday after next );
As opposed to implicitly:
my $dt = DateTime-new( extended = the 3rd Sunday after next );
I think the former is clearer. Though a bit wordy. Of course, there's
nothing prevent parsing modules from offering exportable subroutines.
And in the latter case, how do I distinguish between additional parameters
that indicate another parsing module, and a typo? How about if someone
does this:
my $dt = DateTime-new( year = 2000, month = 12, day = 17,
ISO = '2001-12-11T09:01:23' );
What wins?
Hopefully the above guidelines explain why I've been so vehemently opposed
to some proposals so far. There really is a guiding set of principles at
work here, I'm not just flipping coins.
They do explain your position admirably. It's just that it seems to me
that you've overlooked certain issues here (such as the simple solution
to the mod_perl issues that I've described above).
No, they don't. I was responding to _other_ suggestions! I don't think
you've read the whole thread.
Anyway, here's where the parsing/formatting bit stands.
- The namespace will almost certainly be Date::Formats::*
- Modules in this namespace will implement parsing, formatting, and/or
both.
- strftime may or may not be built-in to DateTime.pm (this is a _very_
minor point, I think)
- parsing and formatting will be done via explicit methods, as opposed to
additional parameters to DateTime-new or a generic DateTime-format
method.
For the actual API, how about this:
# dies if DateTime::Formats::MySQL is not loaded
my $dt = DateTime-parser('MySQL')-from_datetime( $mysql_dt_string );
$dt-formatter('MySQL')-as_datetime(...); # additional params if
Re: timezones
On Tue, 14 Jan 2003, Martijn van Beers wrote: Actually, I recently discovered that Date::ICal _does_ support this. if you do $date-ical (localtime = 1) it prints the time adjusted for the local timezone. Floating time *still* has a timezone. It is just variable. But, since your computer can be in only one spot, it is never ambiguous which timezone it is in. The only time you need this floating timezone is when storing your date (to disk, in a VEVENT, whatever). So Date::ICal doesn't really do anything wrong, it just could be a bit more friendly about it. Like remembering if this was entered as a floating time. How would you handle leap seconds with floating time? Particularly how do you handle leap seconds in a case like this: my $dt = DateTime-new( year = 1997, month = 6, day = 30, hour = 23, minute = 59, second = 59, ( timezone = $utc_zone ) ... or ... ( timezone = $other_zone ) ... or ... ( floating = 1 ) ... or ... ); $dt += DateTime::Duration-new( seconds = 2 ); What is $dt now? If it were UTC, the time would be 1997-07-01 00:00:00, right? If it were some other time zone the time would be 1997-07-01 00:00:01. But if its floating, how do you decide? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Parsing/Formatting API
On Wed, 15 Jan 2003, Jean Forget wrote: Who needs %E* and %O* modifiers? I need them. The traditional way to write a FR year is to use Roman numerals. So, while %Y gives you the Indian-Arabian numerals (2003), %EY gives you the Roman numerals (MMIII). At the same time, while %j gives you the 1..366 number of a day, %Ej gives you the designation of the day (which was meant to replace the saint of the day). So what about %O*? Apparently that does Roman numerals, at least sometimes. Where is this stuff actually defined? I discovered about %E* and %O* in AIX's date(1) manpage. Nothing about that in Linux's date manpage. The basic specifiers are pretty much consistently defined, but not so for %E* and %O*. And maybe I inadvertently swapped %EY and %OY about Roman numerals. I don't mind adding Roman numeral strftime specifiers. For saint days, you're on your own. This would belong in an add in module (or set of modules, one per language/religion combo? ;) ). I coded %Ej for French Revolutionary calendar because it is simple. Gregorian saints are much more difficult because of mobile holidays (Easter, most notably). If nobody has enough time or energy to spare about exotic %E* and %O* modifiers for Gregorian calendar, just forget about them. Jean -- WYGIWYGAINGW = What You Get Is What You're Given And It's No Good Whining. Archichancelier Mustrum Ridcully (cité par Terry Prachett dans The Science of Discworld)
