I figured that if DST is applied locally, the clock is one hour ahead of
"normal" GMT (which hasn't DST applied), so this hour has to be deducted
from the time difference. If the GMT has DST set on, this hour has to be
added to the time difference, hence the double deduction.

Advertisements

On Mon, 04 Apr 2005 17:34:31 +0200, Gunnar Hjalmarsson wrote:
>> I want to calculate the time zone offset (as an integer), and I don't
>> want to depend on other modules.
>
> Why not?

For different reasons:
- I use this in a module that will be used in mod_perl. I want to keep the
number of loaded modules as concise as possible, because of the server
memory overhead; - I want to be able to distribute this module without
people having to install other modules;

>> I figured that if DST is applied locally, the clock is one hour ahead
>> of "normal"
>
> That may be true in many countries, but can you rely on it?

I truly don't know. That's part of the reason I posted this Anyone...?
>> If the GMT has DST set on,
>
> AFAIK, that's never happening.

$tzoffset, if you are going to make it an integer should be in units
of 1 second, not hours. There a places in the world where the offset
is not a whole hour. (e.g., Newfoundland, Tehran, Kabul, Rangoon,
Kathmandu, Darwin)

Leendert Bottelberghs wrote:
> - I use this in a module that will be used in mod_perl. I want to keep the
> number of loaded modules as concise as possible, because of the server
> memory overhead; - I want to be able to distribute this module without
> people having to install other modules;

Well, is it safe to use the modules that come bundled with perl, so
you might as well use them.
-Joe

On Tue, 05 Apr 2005 00:35:32 -0700, Joe Smith wrote:
> Leendert Bottelberghs wrote:
>
>> - I use this in a module that will be used in mod_perl. I want to keep the
>> number of loaded modules as concise as possible, because of the server
>> memory overhead; - I want to be able to distribute this module without
>> people having to install other modules;
>
> Well, is it safe to use the modules that come bundled with perl, so
> you might as well use them.

On Tue, 05 Apr 2005 00:46:45 -0700, Joe Smith wrote:
> Leendert Bottelberghs wrote:
>> I want to calculate the time zone offset (as an integer)
> The international standard for time zone offset is a five-character
> string. A plus or minus sign, two digits for hours, two digits for
> minutes.

Youre right. So I have to use POSIX to be able to calculate the difference
in seconds. I now have the following to calculate and format the time
offset:

On Tue, 05 Apr 2005 06:20:15 -0700, Mothra wrote:
>
> Yor are reinventing what we already have done in the DateTime Project

I know, and I'm not entirely happy with it. But there are good reasons for
it. First of all, I couldn't get the DateTime module installed with CPAN.
Besides the fact that it depends on about a douzen other modules (and it
installs about 60), it just wouldn't compile (running RH8, perl 5.8.0). It
returned:

<snippet>
/usr/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
</snippet>

The second reason I already mentioned: it depends on loads of other
modules. Since the module I'm writing is part of a larger project, I don't
want to force other people (on varying OSs) to install this large amount
of third-party modules.
> use strict;
> use warnings;
> use diagnostics;
> use DateTime;
>
>
> my $dt = DateTime->now(time_zone => 'America/Chicago');
>
> print $dt->offset();

Do you have to specify the timezone manually? And can the offset be
formatted in the "standard" timezone-offset way automatically with this
module?

"Leendert Bottelberghs" <> wrote in
message news...
> On Tue, 05 Apr 2005 06:20:15 -0700, Mothra wrote:
> >
> > Yor are reinventing what we already have done in the DateTime Project
>
> I know, and I'm not entirely happy with it. But there are good reasons for
> it. First of all, I couldn't get the DateTime module installed with CPAN.
> Besides the fact that it depends on about a dozen other modules (and it
> installs about 60), it just wouldn't compile (running RH8, perl 5.8.0). It
> returned:

Please report your failures to the DateTime Mailing list if you are having problems installing DateTime
we need to know about it.
>
> The second reason I already mentioned: it depends on loads of other
> modules. Since the module I'm writing is part of a larger project, I don't
> want to force other people (on varying OSs) to install this large amount
> of third-party modules.

You would be better off installing DateTime that reinventing the wheel. As
far
as I know it is the only suite of modules that incorporate the Olson
Timezone
Database. Timezone conversion is fully supported (along with offsets)
>
> > use strict;
> > use warnings;
> > use diagnostics;
> > use DateTime;
> >
> >
> > my $dt = DateTime->now(time_zone => 'America/Chicago');
> >
> > print $dt->offset();
>
> Do you have to specify the timezone manually? And can the offset be
> formatted in the "standard" timezone-offset way automatically with this
> module?

Yes, you can use the naming convention provided with datetime or
you can specify an offset. I ran into a similar issue when writting the
tests
for the Sunrise module. I could not use the standard naming provided with
DateTime I had to use the offset, something like this

use strict;
use warnings;
use diagnostics;
use DateTime;
use DateTime::TimeZone;
use POSIX qw(floor ceil);

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!