Just out of curiousity...why the '_datetime' suffix on these methods?
Isn't that redundant? Or was it assuming that these methods might be
showing up in classes outside of the DateTime namespace?
And speaking of brevity...the 0.18 docs for DateTime say that
'time_zone_long_name' is short for
Was there a compelling reason not to have a class method analagous to
DefaultLocale() for timezones, such as DefaultTimezone()?
And if it were present, am I alone in finding it useful for the Format
modules, such as DT::F::MySQL, where the zoneless strings are forced
into the 'floating'
Just out of curiousity...why the '_datetime' suffix on these methods?
Isn't that redundant? Or was it assuming that these methods might be
showing up in classes outside of the DateTime namespace?
To differentiate from: _date, _time, _span, etc.
And speaking of brevity...the 0.18 docs for
* Dean Thayer ([EMAIL PROTECTED]) [05 Nov 2003 11:04]:
Is anyone working on a module to convert time strings in the format
used by Tivoli Enterprise Console to DateTime objects? I was going to
do so, and I figured I would check. Also, would you want that module
included in the DateTime
Hi All,
I have recently updated the test scripts for the
Astro::Sunrise module and would like to incorporate these
changes into the DateTime::Event::Sunrise test suite. However,
I am unable to map an offset into a datetime timezone. Is
there a way to take an offset say -8 hours and look this up
On Wed, 5 Nov 2003, Matt Sisk wrote:
Just out of curiousity...why the '_datetime' suffix on these methods?
Isn't that redundant? Or was it assuming that these methods might be
showing up in classes outside of the DateTime namespace?
Because we can parse and format things that aren'ts
On Wed, 5 Nov 2003, Matt Sisk wrote:
Was there a compelling reason not to have a class method analagous to
DefaultLocale() for timezones, such as DefaultTimezone()?
Nope, no particular reason. But thinking about it, it seems like a bad
idea. Locale is something that I would think the end
On Wed, 5 Nov 2003, Hill, Ronald wrote:
I have recently updated the test scripts for the
Astro::Sunrise module and would like to incorporate these
changes into the DateTime::Event::Sunrise test suite. However,
I am unable to map an offset into a datetime timezone. Is
there a way to take an
Dave Rolsky wrote:
No, because there's plenty of timezones for every offset. For example, at
-08:00 base offset from UTC we have America/Los_Angeles, America/Juneau,
America/Whitehorse, America/Dawson, America/Tijuana, and
America/Vancouver.
So which one of those corresponds to -8 hours?
It would
On Wed, 5 Nov 2003, Matt Sisk wrote:
And as a convenience, I was suggesting this as equivalent:
$dt3 = $dt1-clone(%overrides);
If the set() method accepted a time_zone parameter (which is trivial to
add), wouldn't this be equivalent to:
$dt3 = $dt1-clone-set(%overrides);
??
-dave
At 21:57 -0600 2003-11-05, Matt Sisk wrote:
Rick Measham wrote:
The problem above is that $dt-parameters() may return a key
included in %overrides. So how about $dt-parameters( %overrides )?
As I corrected myself earlier, I should have made the $dt in
$dt-parameters() more generic, rather
On Thu, 6 Nov 2003, Rick Measham wrote:
But the same problem exists ... %parms will contain locale =
'en_AU', so your call to set is now:
$dt3-set( locale='en_AU', year=2003 .. second = 27, time_zone = '-1100',
locale='latvia'
);
So which locale gets used?
The second. It's
12 matches
Mail list logo
