Re: DT::Wrapper API/semantics
On Fri, 8 Aug 2003, Flavio S. Glock wrote: Dave Rolsky wrote: Anyway, does this API sound sane? And if it does, anyone have any really clever implementation ideas? I have some scary ones involved AUTOLOAD and constructing classes on the fly. help me understand it - Does something like DT::Incomplete could be a wrapping class? No, this is so that we can mix and match additional behaviors that would otherwise be done as subclasses. Joshua's caching class is one obvious example. Another might a class that didn't die on invalid params, but converted them to something valid. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime used with Class::DBI
Answering to Rick Measham (Fri, 8 Aug 2003 10:29:08 +1000)
At 4:13 PM -0700 7/8/03, Matthew McGillis wrote:
[snip]
Casey offers a better solution for the problem you describe, however
you *could* (as apposed to should) also do the following (not the
safest thing to do, but it works):
In your own code put something like:
*DateTime::format_how_I_want = sub {
# method to turn the datetime in $_[0] into the string you need
}
Then in Class::DBI you can use:
DateTime-format_how_I_want();
Once again, let me say (because if I don't, Dave will) that this is
not recommended behaviour. It's not a good thing to play around
inside other module's namespaces.
Why not use subclassing? A few days ago, I attended M-J.D.'s talks in
YAPC::Europe in Paris, and in one of them he just advised something
like that. You do not play around somebody else's namespace,
you reuse it to make your own namespace. When you remove all
the buzzwords, OO is just a few good ideas, and subclassing
is one of them.
Jean Forget
--
And now we have the World Wide Web (the only thing I know of
whose shortened form --- www --- takes three times longer to say than
what it¹s short for).
-- Douglas Adams, the Salmon of Doubt
ANNOUNCE: DateTime 0.1601
0.1601 2003-08-07 [ BUG FIXES ] - On platforms like Win32, where we can't find a finite() or isfinite() function/macro, the DateTime::LeapSecond code wasn't being loaded, so many tests failed. Reported by Ron Hill. Thanks, Ron. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Get the right C compiler?
This make sense? make's default $(CC) may have no relation to
the one Perl was compiled with, so shouldn't we use what
knowledge we can get?
Index: Makefile.PL
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v
retrieving revision 1.31
diff -u -r1.31 Makefile.PL
--- Makefile.PL 24 Jul 2003 03:54:50 - 1.31
+++ Makefile.PL 9 Aug 2003 13:13:55 -
@@ -31,7 +31,7 @@
close F or no_cc();
my $make = $^O =~ /win32/i ? 'nmake' : 'make';
-system($make test$Config{obj_ext}) and no_cc();
+system(CC=$Config{cc} $make test$Config{obj_ext}) and no_cc();
if ( -d 'CVS' )
{
DateTime used with Class::DBI
I'm not sure anyone is interested but I thought I would pass this along. I have started using Class::DBI and was hoping I could also use DateTime with it. Class::DBI has some hooks to allow for any type of Object to represent Time. However the one limitation it has is that you must be able to call a method with no parameters to produce the proper output for the database. So the only way I could use DateTime with it is if $datetime-somename() produces the correct format for the database I'm using. I have taken a look at the DateTime-Format-MySQL and it can produce the formats required however with out being able to get the format through a call as described above it will never work with Class::DBI. This isn't exactly a DateTime problem or a Class::DBI problem or a Database problem just an interaction issue that someone may or may not be interested in looking at. However as the two objects operate today I don't see them being compatible. If you are interested and have any additional questions feel free to ask. Thanks Matthew McGillis
RE: Get the right C compiler?
Hi Iain.
* Dave Rolsky ([EMAIL PROTECTED]) [10 Aug 2003 00:38]:
On Sat, 9 Aug 2003, Iain Truskett wrote:
This make sense? make's default $(CC) may have no relation to
the one Perl was compiled with, so shouldn't we use what
knowledge we can get?
[snipped]
Good question. Not sure. At the very least it means it gets it correct
for one Solaris box I have access to.
[snipped]
How about something like this:
use strict;
use warnings;
use Config;
print $Config{make};
on my system this prints:
F:\scriptsx.pl
nmake
maybe something like this may be helpful.
cheers,
--
Iain.
Ron Hill
Re: RFC: DateTime::TimeZone::LMT
On Thu, 14 Aug 2003, Sam Vilain wrote: A good point. This is needed so that when we serialize DateTime objects, we don't need to serialize the timezone object too. A good point - are you providing these methods for some of those `other' :) persistence tools ? Storable: $dt-STORABLE_freeze $dt-STORABLE_thaw This exists. Pixie: DateTime::px_is_storable $dt-px_freeze $dt-px_thaw This doesn't, but could probably share the same code as the Storable hooks. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime-localtime()
On Sunday, August 10, 2003, at 08:59 PM, Joshua Hoblitt wrote:
If you only have a year and day of year, then having a
from_day_of_year
constructor saves a _lot_ of calculation that end users have to do.
OTOH,
having to do 'DateTime-now(time_zone = local)' isn't very onerous
at
all.
If you need an example DT::F::ISO8601 makes heavy use of
from_day_of_year().
I was thinking of end-user code more than DT-related library code. But
I'm not really arguing against having from_day_of_year() anyway. I'm
arguing for a simpler way to get the current local time because, IME
with DT and other date libraries, this is a *very* common task.
Heck, if the API Stability Gods of the 0.1x Phase of Development could
somehow be appeased, I'd argue that now() should actually default to
time_zone = 'local' because that's what users will expect--and what
now() sounds like to me. But I suspect the Gods will not be
appeased, thus the localtime() compromise.
C'mon, it's one innocent little line... :)
sub localtime { shift-now(time_zone = 'local', @_) }
Is this the horrid face of code bloat, or an honest effort to address a
common usage scenario?
Besides, I thought the whole point of not having a single new()
constructor that understands many kinds of args was that creating
specialized constructors was a cleaner way to add such functionality.
And now we're balking at actually using this mechanism to add a
constructor whose usage, IMO, will be second only to new() in end-user
code?
-John
Re: DT::TZ test failure
Okay, so maybe a new constructor then? DateTime-localtime()? Getting
the current local time seems more common than, say, constructing a
DateTime object from a day of the year, IMO :)
We have enough constructors as it is. I could be talked into:
DateTime-now( time_zone = 'local' );
But that would add extra overhead on every call to now();
Whats wrong with:
DateTime-now-set_time_zone( 'local' );
or
sub here_now { DateTime-now-set_time_zone( 'local' ) }
?
If your going to insist on another constructor you could write it as a decorator with
our new plug-in architecture. :)
-J
--
Re: RFC: DateTime::TimeZone::LMT
Maybe there should be an extra accessor -link_name. (They're called links in the TimeZone innards). Then when -time_zone_short_name is called and it has no value, it return -link_name. Same for long_name. I don't like that at all. You really should be creating new classes with your specified short names. Otherwise this might break somebody else's code that is relying on the default behavior. -J --
Re: leap seconds in XS
On Wed, 6 Aug 2003, Dave Rolsky wrote: I just checked this in, but I'm not sure if it's much faster. It'd be good if someone who knows more about about C could look at the implementation and see if there's anything they can think of to improve it. Also, I should probably change the generated code to use the binary search method that Flavio's DateTime::LeapSecond generated code uses. Ok, I did some benchmarks and it looks like date math involving leap seconds (basically an DateTime object where the time zone is _not_ floating) has sped up about 10% or so, which is definitely a good thing. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::Format::Builder 0.76
Changes for 0.76 (10 Aug 2003) - Fallthrough example and test added. - Quick parser added to simplify fallthrough stuff. - Rejigged internals to allow for on_fail argument to multi-parsers. cheers, -- Iain. pgp0.pgp Description: PGP signature
Re: RFC: DateTime::TimeZone::LMT
On Mon, 12 Aug 2003, Rick Measham wrote: Attached is the above module. Unless there's strenuous objections I'll CPAN it. I just wish for this and for ::Alias that we could hook in better without messing with the internals. While I'm thinking of it, I'd like to be able to set names and short-names for offsets. I have a list of short names in Strptime, but I've love to be able to get these back from TimeZone somehow. Just like we do with Olsen (or is it Olson, one's the twins, one's the time, can't ever remember which!). I like the idea, but the longitude needs to be settable per object, not just for the whole class. Otherwise two modules couldn't both use this one! This also makes the whole name thing moot, since the object would always return LMT for the name. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
[patch] use DT in Astro::Sunrise
Hi Ron,
Here is a 'eating our own dog food' patch against Astro::Sunrise 0.8. :)
Cheers,
-J
--
diff -ur Astro-Sunrise-0.8/Makefile.PL Astro-Sunrise-0.8.new/Makefile.PL
--- Astro-Sunrise-0.8/Makefile.PL 2003-02-27 05:05:20.0 -1000
+++ Astro-Sunrise-0.8.new/Makefile.PL 2003-08-06 19:02:35.0 -1000
@@ -4,5 +4,5 @@
WriteMakefile(
'NAME' = 'Astro::Sunrise',
'VERSION_FROM' = 'Sunrise.pm', # finds $VERSION
-'PREREQ_PM' ={ 'Time::Piece' = 1.08, },
+'PREREQ_PM' ={ 'DateTime' = 0.16, },
);
diff -ur Astro-Sunrise-0.8/Sunrise.pm Astro-Sunrise-0.8.new/Sunrise.pm
--- Astro-Sunrise-0.8/Sunrise.pm2003-02-27 05:10:32.0 -1000
+++ Astro-Sunrise-0.8.new/Sunrise.pm2003-08-06 19:10:29.0 -1000
@@ -82,7 +82,7 @@
use POSIX;
use Math::Trig;
use Carp;
-use Time::Piece;
+use DateTime;
#use Time::Seconds;
use vars qw( $VERSION @ISA @EXPORT @EXPORT_OK $RADEG $DEGRAD );
@@ -579,20 +579,16 @@
my $alt = shift || -0.833;
my $offset = int( shift || 0 );
- my $today = localtime;
- #
- # Not sure why appending a 'D' to the offset didn't work. So converted
- # the days into seconds...
- #
- $today = $today + $offset * 86400;
+ my $today = DateTime-today-set_time_zone( 'local' );
+ $today-add( days = $offset );
my( $sun_rise, undef ) = sunrise( $today-year, $today-mon, $today-mday,
$longitude, $latitude,
- $today-tzoffset-hours,
+ ( $today-offset / 3600 ),
#
- # DST is always 0 because Time::Object
- # currently (v 1.00) adds one to the
- # tzoffset during DST hours
+ # DST is always 0 because DateTime
+ # currently (v 0.16) adds one to the
+ # offset during DST hours
0,
$alt );
return $sun_rise;
@@ -635,20 +631,16 @@
my $alt = shift || -0.833;
my $offset = int( shift || 0 );
- my $today = localtime;
- #
- # Not sure why appending a 'D' to the offset didn't work. So converted
- # the days into seconds...
- #
- $today = $today + $offset * 86400;
+ my $today = DateTime-today-set_time_zone( 'local' );
+ $today-add( days = $offset );
my( undef, $sun_set ) = sunrise( $today-year, $today-mon, $today-mday,
$longitude, $latitude,
-$today-tzoffset-hours,
+( $today-offset / 3600 ),
#
-# DST is always 0 because Time::Object
-# currently (v 1.00) adds one to the
-# tzoffset during DST hours
+# DST is always 0 because DateTime
+# currently (v 0.16) adds one to the
+# offset during DST hours
0,
$alt );
return $sun_set;
Re: DT::TZ test failure
On Sunday, August 10, 2003, at 01:34 PM, Dave Rolsky wrote: On Sun, 10 Aug 2003, John Siracusa wrote: ...speaking of which, is there any chance DateTime-now() can be changed to default to the local time zone? It seems to me that now probably means now, here most of the time. I don't have a single call to now() that doesn't include time_zone = 'local'. This doesn't seem like a good idea, since it's not backwards compatible and since 'local' may not work on every single platform. Well, it is version 0.1x after all... ;) Okay, so maybe a new constructor then? DateTime-localtime()? Getting the current local time seems more common than, say, constructing a DateTime object from a day of the year, IMO :) -John
Re: DateTime-localtime() (was Re: DT::TZ test failure)
I think a constructor aimed at time_zone = 'local' makes sense. If not that, then perhaps a class variable for DEFAULT_TIMEZONE or somesuch. DateTime-now( time_zone = 'local' ); vs. DateTime-local_now; Saves an incredible 18 characters even with generous spacing. Also, regarding the issue of 'local' not always working: I'm not convinced that hard-coding timezones into code is worth the tradeoff (configuring your local timezone every time you install a module, for instance). That will lead to weird errors and a mess of portability issues. Not to mention we don't want to support that mess. I'm not going to insist that now() default to this, but the addition of a constructor that does do this would personally save me a lot of typing. Put a macro in your editor. :) -J --
Re: RFC: DateTime::TimeZone::LMT
A good point. This is needed so that when we serialize DateTime objects, we don't need to serialize the timezone object too. A good point - are you providing these methods for some of those `other' :) persistence tools ? Storable: $dt-STORABLE_freeze $dt-STORABLE_thaw Pixie: DateTime::px_is_storable $dt-px_freeze $dt-px_thaw Not a lot of code for a lot of ease of storage... -- Sam Vilain, [EMAIL PROTECTED] There ought to limits to freedom. - George W. Bush, May 21, 1999, referring to GWBush.com (great site)
Re: DateTime-localtime() (was Re: DT::TZ test failure)
On Sunday, August 10, 2003, at 09:40 PM, Dave Rolsky wrote: ...unless that's the only way you will *ever* call now()! :) Seriously, who is calling now() *without* time_zone = 'local' arguments? I haven't done so yet, and would like to hear some examples of this usage. Me, because I know that 'local' won't always work ;) I'd be more likely to call it with an explicit time zone than with 'local'. Yeah, but as the module's author, you're not exactly the typical user ;) Here's example of what I expect to be common usage. Let's say someone want the default date range in the text fields on a web form to be the past 30 hours. Joe Perl Programmer is going to glance at the DT docs and then write: $start = DateTime-now-subtract(hours = 30)-strftime(...); $end = DateTime-now-strftime(...); Joe Perl Programmer is going to be very surprised, IMO, and the fix is not to add warnings to the docs... ;) Like I said, I think there are very good reasons not to default to local, especially since that it won't necessarily work at all. Okay, fine, then don't default now() to 'local' to avoid that problem. But what's the argument against a localtime() that, say, croaks if it can't figure out what local is? I think that's a reasonable thing for a function named localtime() to do. Do you not agree that getting the current local time will be a common task, and that Joe Programmer is not likely to be too keen on typing either time_zone = 'local' or time_zone = 'Asia/Taipei' (or whatever) everywhere? -John
Re: RFC: DateTime::TimeZone::LMT
On Tue, 12 Aug 2003, Claus Färber wrote: Rick Measham [EMAIL PROTECTED] schrieb/wrote: While I'm thinking of it, I'd like to be able to set names and short-names for offsets. For short names, that might be a good idea. But for long names, it would break this: | name | Returns the name of the time zone. If this value is passed to the | new() method, it is guaranteed to create the same object. A good point. This is needed so that when we serialize DateTime objects, we don't need to serialize the timezone object too. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::TimeZone::LMT
On Tue, 2003-08-12 at 07:11, Joshua Hoblitt wrote: While I'm thinking of it, I'd like to be able to set names and short-names for offsets. I have a list of short names in Strptime, but I've love to be able to get these back from TimeZone somehow. Just like we do with Olsen (or is it Olson, one's the twins, one's the time, can't ever remember which!). This is exactly what DT::TZ::Alias does. It does? How? From what I can make out, Alias just allows me to create aliases. If I create an alias 'EST' = 'UTC', then the short name I get back would be UTC right? Or if I create 'EST' = 1000, then I don't get a short name, I get '1000'. What I want is the reverse of what alias does. Or rather I'd like timezone to remember what value it was created with. If I create an alias 'EST' = 'UTC' and then create a datetime with 'EST', I'd like to get EST as the name rather than UTC. What do people think? I can provide patches for this if I'm not the only one who'd find it useful. Cheers! Rick
Re: RFC: DateTime::TimeZone::LMT
What I want is the reverse of what alias does. Or rather I'd like timezone to remember what value it was created with. If I create an alias 'EST' = 'UTC' and then create a datetime with 'EST', I'd like to get EST as the name rather than UTC. Awww - I understand what your asking for now. We would have to provide some sort of registration facility in DT::TZ. What do people think? I can provide patches for this if I'm not the only one who'd find it useful. Can you give an example of what this would be used for? -J --
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: DT::TZ test failure
If you only have a year and day of year, then having a from_day_of_year constructor saves a _lot_ of calculation that end users have to do. OTOH, having to do 'DateTime-now(time_zone = local)' isn't very onerous at all. If you need an example DT::F::ISO8601 makes heavy use of from_day_of_year(). -J --
Re: DateTime-localtime() (was Re: DT::TZ test failure)
On Sun, 10 Aug 2003, John Siracusa wrote: If you only have a year and day of year, then having a from_day_of_year constructor saves a _lot_ of calculation that end users have to do. OTOH, having to do 'DateTime-now(time_zone = local)' isn't very onerous at all. ...unless that's the only way you will *ever* call now()! :) Seriously, who is calling now() *without* time_zone = 'local' arguments? I haven't done so yet, and would like to hear some examples of this usage. Me, because I know that 'local' won't always work ;) I'd be more likely to call it with an explicit time zone than with 'local'. Here's example of what I expect to be common usage. Let's say someone want the default date range in the text fields on a web form to be the past 30 hours. Joe Perl Programmer is going to glance at the DT docs and then write: $start = DateTime-now-subtract(hours = 30)-strftime(...); $end = DateTime-now-strftime(...); Joe Perl Programmer is going to be very surprised, IMO, and the fix is not to add warnings to the docs... ;) Like I said, I think there are very good reasons not to default to local, especially since that it won't necessarily work at all. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Re: [rfc] HiRes
So are we back to DT::HiRes? Or just rename the constructor? I would like to see this functionality make it into the next release. I guess sticking it in a separate module DateTime::HiRes works, since that way we don't force people to load Time::HiRes if they don't need it. What about using 'require Time::HiRes' inside the hires constructor? My thinking is since we already have hires_epoch() in the DT namespace we might as well have hires_now() there too. -J --
RFC: DateTime::TimeZone::LMT
Attached is the above module. Unless there's strenuous objections I'll
CPAN it. I just wish for this and for ::Alias that we could hook in
better without messing with the internals.
While I'm thinking of it, I'd like to be able to set names and
short-names for offsets. I have a list of short names in Strptime, but
I've love to be able to get these back from TimeZone somehow. Just like
we do with Olsen (or is it Olson, one's the twins, one's the time, can't
ever remember which!).
Cheers!
Rick
package DateTime::TimeZone::LMT;
use strict;
use Carp qw( croak );
use DateTime::TimeZoneCatalog;
use vars qw( $VERSION $LONGITUDE $OFFSET );
$VERSION = 0.01;
sub import {
my $class = shift;
return unless @_;
$class-set( @_ );
}
sub set {
my $class = shift;
my $longitude = shift;
if ($longitude) {
croak You must supply a valid longitude. (-180 .. 180) if ($longitude -180 or $longitude 180);
# Offset in seconds:
my $offset_seconds = ( $longitude / 180 ) * (12 * 60 * 60);
my $sign = '+';
if ($offset_seconds 0) {
$offset_seconds *= -1;
$sign = '-';
}
my $hours = int($offset_seconds / (60 * 60) );
$offset_seconds -= $hours * (60 * 60);
my $minutes = int($offset_seconds / 60);
$offset_seconds -= $minutes * 60;
my $seconds = sprintf(%.0f,$offset_seconds);
$OFFSET = $sign$hours:$minutes:$seconds;
$DateTime::TimeZone::LINKS{ LMT } = $OFFSET;
$LONGITUDE = $longitude;
}
return $LONGITUDE;
}
sub offset {return $OFFSET};
1;
__END__
=pod
=head1 NAME
DateTime::TimeZone::Alias - Create aliases for DateTime timezones
=head1 SYNOPSIS
use DateTime::TimeZone::LMT qw/145.08009/;
# or
use DateTime::TimeZone::LMT;
DateTime::TimeZone::LMT-set(145.08009);
DateTime::TimeZone::LMT-longitude;
# 145.08009
DateTime::TimeZone::LMT-offset;
# +09:40:19
=head1 DESCRIPTION
Creates LMT DateTime timezones. This module violates
the encapsulation of the DateTime internals. User _Beware_.
=head1 BACKGROUND
Local Apparent Time
If we are to tell the time by the sun's hour angle, no two points will share
the same time unless they lie on the same meridian. The time is thus
Ilocalised to a particular meridian, and since it is also based on the
apparent (think 'appear') motion of the sun we call it Local Apparent Time.
This is the kind of time shown on most sundials, and until about a century
ago was the kind of time used almost universally in daily life. Yet it suffers
from disadvantages which have led most people to discard it in favor of some
other kind of time.
For one thing it is inconvenient to use a system of timekeeping which is so
narrowly localised. Remember that no two points will share the same LAT unless
they lie on the same meridian. Two cities 100 miles apart will differ by about
7.5 minutes. There is even a difference of about 0.25 seconds at opposite ends
of a football field! Precisely set clocks would even show slightly different
times in different rooms of the same house!
Local Mean Time
The second disadvantage of LAT arises from the fact that when we measure days
by the sun they turn out to differ amongst themselves in length. About Christmas
time the days are about 30 seconds longer than average and in mid-September are
about 20 seconds shorter. These variations increase until in mid-February when
the sun reaches its meridian almost 14.5 minutes later than it would if all
days were of equal length. Then in early November the meridian falls back about
16.5 minutes. These variations amount to just over half-an-hour which would be
decidedly inconvenient for scientific purposes, and today we would consider it
unacceptable for even everyday affairs.
Instead, then, of reckoning time from the irregularly moving real sun, we
usually reckon it from an imaginary imean sun -- a fictitious heavenly body
which moves at a constant speed, equal to the average speed at which the
real sun moves. Time measured accoring to this mean sun is known as ILocal
Mean Time. This is the time that this module works with.
=head1 IMPORT PARAMETERS
Accepts a scalar containing a valid longitude.
=head1 METHODS
=over 4
=item * set( $longitude )
Sets the longitude.
=item * longitude( $longitude )
Sets the longitude if one is provided.
Returns the current longitude.
=item * offset()
Returns the current longitude's UTC offset.
=back
=head1 NOTES
=head2 Import
Multiple Cuse DateTime::TimeZone::LMT statements in the same package will
cause unexpected behaviour. If you need more than one LMT, consider using
CDateTime::TimeZone::Alias as detailed in the Cookbook below.
=head1 COOKBOOK
=head2 What is my LMT?
To determine the time right where you are, get your longitude. Look it up in
an atlas or look it up online. There are online services that let you enter
your address and they return a very accurate value. Then:
use DateTime;
use DateTime::TimeZone::LMT $your_longitude;
print DateTime-now( time_zone = LMT )-datetime;
Re: DT::TZ test failure
DateTime-now( time_zone = 'local' ); It already works this way. See what happens when I read my email before morning coffee. :) -J --
Re: leap seconds in XS
Dave Rolsky wrote: Ok, I did some benchmarks and it looks like date math involving leap seconds (basically an DateTime object where the time zone is _not_ floating) has sped up about 10% or so, which is definitely a good thing. How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ? - Flavio S. Glock
Re: leap seconds in XS
How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ? Seems like a good idea. Do you want to do it or should I? I'd like to keep it separated. I believe it maybe useful outside the context of DT. -J --
Re: RFC: DateTime::TimeZone::LMT
Rick Measham [EMAIL PROTECTED] schrieb/wrote: While I'm thinking of it, I'd like to be able to set names and short-names for offsets. For short names, that might be a good idea. But for long names, it would break this: | name | Returns the name of the time zone. If this value is passed to the | new() method, it is guaranteed to create the same object. Claus -- http://www.faerber.muc.de -- http://www.bayern-gewinnt.de/
