I've created public git repositories for my datetime-related Perl modules:
git://lake.fysh.org/zefram/DateTime-TimeZone-SystemV.git
git://lake.fysh.org/zefram/DateTime-TimeZone-Tzfile.git
git://lake.fysh.org/zefram/DateTime-TimeZone-Olson.git
git://lake.fysh.org/zefram/App-olson.gi
Anthony Ball wrote:
>a way to query when the DST changes happen.
That'll need additions to the API for the timezone objects. I've got
some plans to do that, but it's a later stage.
-zefram
but I think I'm going to handle them by a radical
refactoring that yields more of a query language than this collection
of options.
-zefram
#!perl
{ use 5.006; }
use warnings;
use strict;
use Date::ISO8601 0.000 qw(present_ymd);
use DateTime::TimeZone::Olson ();
use DateTime::TimeZone::Syst
So I'm inclined to keep DT:TZ and allied code free of any real dependency
on DateTime.
-zefram
at it ought to additionally support.
-zefram
#!perl
{ use 5.006; }
use warnings;
use strict;
use Date::ISO8601 0.000 qw(present_ymd);
use Date::JD 0.005 qw(rdn_to_cjdnn);
use DateTime::TimeZone::Olson ();
use Getopt::Std qw(getopts);
use Params::Classify qw(is_string);
use Time::OlsonTZ::Data ()
mpletely unfounded. Olson and Eggert have rejoined the database
maintenance mailing list, which is remaining at its new home supplied
by IANA. Robert Elz is still releasing new versions of the database,
but the coordination job may well shift back to Olson imminently.
Essentially, the episode is over.
-zefram
.
>You can't add 365 days because that falls afoul of the leap year problem.
You can ask DateTime for that too:
$dt->add(days=>365);
It's nicer, in that day addition *is* associative. Of course, a quarter
of the time (when the 365 days spans a leap day), the 365-days-later
won't be the same-date-next-year. Is that what you mean by the "leap
year problem"?
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201202.tar.gz
size: 215450 bytes
md5: c30730b5e92d47a5a5e6fbb0a3ed2481
Changes from the previous release:
* Olson database version 2012b (code 2012b, data 2012b): 440 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201201.tar.gz
size: 215399 bytes
md5: e6556bbb924abb7f8e018d58c66df700
Changes from the previous release:
* Olson database version 2012a (code 2012a, data 2012a): 440 canonical
.
PDF would be a very silly format for this. If you're concerned about
the size, just gzip it.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201114.tar.gz
size: 215462 bytes
md5: 816ca2268b8d743235832b507c5f4b62
Changes from the previous release:
* Olson database version 2011n (code 2011i, data 2011n): 439 canonical
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201113.tar.gz
size: 215785 bytes
md5: 85a8dd756e92ec89b09dd65d1bbca7ba
Changes from the previous release:
* Olson database version 2011m (code 2011i, data 2011m), with one-off
fix
Jon Bjornstad wrote:
>Am I missing something?
Not really. It's an undocumented limitation of Convert::NLS_DATE_FORMAT,
which is used internally by DateTime::Format::Oracle.
-zefram
ch with
/usr/share/zoneinfo. Its very purpose is to be consistent across
platforms, independent of the host's native timezone database.
DT:TZ:Local is about matching host behaviour, and with DT:TZ:Tzfile
available it should be fairly easy to get it reading /usr/share/zoneinfo.
-zefram
oaching switching to git, at
which point I'll most likely publish repos, which in the T:OTZ:D case
will include the automatic build code.
-zefram
ari.oz.au. I'm treating such releases as
canonical versions of the Olson database. Dave Rolsky has indicated
to me that he's likewise accepting them for the purposes of making new
versions of DT:TZ.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201112.tar.gz
size: 214778 bytes
md5: fcfc9e47de53ee49d4f1f417add98f4b
Changes from the previous release:
1
-zefram
the new list if you weren't previously intending to subscribe
to tz@elsie.
-zefram
ty. It's all been
helped by the nearly-complete IETF work to establish a long-term process
for maintenance of the database.
-zefram
ating,
and supporting our software as before. There will merely be no imminent
new version of the Olson database. We must watch to see whether this
will be a protracted state of affairs, and if so see what consensus
emerges about the future of the database.
-zefram
-bit version of the file, which is exactly what
DT:TZ:Tzfile does. I'm treating this as a showstopper for replacing
DT:TZ. I've reported the problem to the Olson folks.
-zefram
alendar
date was avoided by simultaneously switching from the Julian Calendar
(as used by Russia) to the Gregorian Calendar (as used by the US).
-zefram
tch the exception.
>Any suggestions how to work around this issue?
It all depends on what you're trying to achieve.
-zefram
Karen Etheridge wrote:
>So, if you're not going to generate a pod that contains this list at build-
>or install-time, please provide an executable (App::Cmd is nice!) that
>generates the list on the fly.
Thanks for the comments. I'm leaning towards the command-line tool
approach.
-zefram
Then you'd be daft to use DateTime.
-zefram
not sure which behaviour
'time_zone => "local"' ought to invoke. DT:TZ:Local hasn't so far been
precise enough to distinguish between the two philosophies.
Thanks for your comments.
-zefram
due to offset change at -e line 1
The error message is now very informative. The new option to override
the zone name (which was previously always the recipe) will be used
by DT:TZ:Tzfile in order to get the right name in this error message.
(DT:TZ:SystemV supplies the far-future part of DT:TZ:Tzfile.)
New DT:TZ:Tzfile tomorrow. Then DT:TZ:Olson. Then DT:TZ.
-zefram
earlier, it's easy to write code around that to present it
as POD, or in any other human-oriented format. We could provide a
command-line program that wraps that. How easy does it have to be?
I'd be interested to hear from people who actually use the current
DT:TZ:Catalog document.
-zefram
ime,
if that's done in any distro other than Time::OlsonTZ::Data. I'm not
inclined to put it there, because I'm not seeing the value in such
a document.
-zefram
You can make a note of it in
>the Changes file.
OK.
>Whatever works for you. As long as it's publicly available and in the distro
>metadata, I'm happy. I just don't want the project to become less visible
>after you take it over.
I'll look into that.
>Yeah, that's a good point. I guess I'm fine with not having comaint.
OK, cool.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.20.tar.gz
size: 214430 bytes
md5: 98b00dc30eee4100d4cac8a269db6c2a
Time-OlsonTZ-Data-0.20 is based on version 2011k of the Olson
database. It contains 439 canonical zones and 142
advanced usage
would be to automatically pick one of the candidates (on what basis I
don't know) and either use the zone as a whole or apply its DST rules
while staying within the POSIX limits of what the zone spec could mean.
This could potentially be useful default behaviour somewhere within DT:TZ.
-zefram
its terms of service (and neither should you).
>As far as maintenance, I would like to have comaint, although I'm not
>sure how much good that will really do me since all the real work is done
>in other distros anyway. But it'll make me feel better ;)
I also have difficulty imagining how it would be useful, but I have
little experience with this. One other person has co-maint on one of
my modules, the first one that I span off from $ork, and he's never
used it. If I drop off the net for an extended period without making
maintenance arrangements, you can always go the takeover route, and
you could probably get a fast-tracked co-maint that way if there were
something requiring immediate attention. So I don't see any situation
where you'd validly use co-maint that you have only via this handover
arrangement, but I can't sensibly deny it.
-zefram
I've spent the past week reinventing a wheel.
http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.900.tar.gz
size: 29025
MD5: 812934a0174783eb8bdd37f6c99175d6
SHA1: 7d4e73b10574534667a48f2f148b09bef1d0a541
This is a total rewrite of DateTime::TimeZone. The main purpose of the
change is tha
#x27;s logically a function, nothing else.
-zefram
Bill Moseley wrote:
>The other approach is a utility module using Exporter[*] -- then do
> is_in_future( $dt ), but I'm not thrilled by that.
This is the most sensible approach. It won't step on anyone else's toes.
Don't worry too much about which syntax you're using.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201110.tar.gz
size: 214536 bytes
md5: 9d12151e1a341863e9fd8395461d6b0c
Time-OlsonTZ-Data-0.201110 is based on version 2011j of the Olson
database. It contains 438 canonical zones and 142
Andrew O'Brien wrote:
>Worth a doc patch or is it just me that finds this slightly confusing?
Definitely worth a doc patch. Well volunteered.
-zefram
.
The parsing is done by a regexp underneath, and the regexp is something
like /(\d{8})(\d+)(\d+)(\d+)\.(\d+):000/. It all works if you give
everything explicit field widths, "%8e%2H%2M%2S.%9N:000".
-zefram
Olivier Mengu? wrote:
>Thanks for your help, but I do not plan to reimplement the algorithm myself.
>I prefer to use a trusted implementation already available on the CPAN.
Date::ISO8601 would appear to be what you want.
-zefram
me tries to do the
whole job but suffers from the unavoidable complexity; Date::ISO8601 is
much cleaner but at the expense of only doing a much narrower job.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201109.tar.gz
size: 214403 bytes
md5: 4e03633402e3c306d07e6cdb925efaf0
Time-OlsonTZ-Data-0.201109 is based on version 2011i of the Olson
database. It contains 438 canonical zones and 142
et
from $dt->utc_rd_as_seconds and $dt->local_rd_as_seconds.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201108.tar.gz
size: 218599 bytes
md5: 7cdacd422103d2066b0574602aed3fcb
Time-OlsonTZ-Data-0.201108 is based on version 2011h of the Olson
database. It contains 437 canonical zones and 142
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201107.tar.gz
size: 222792 bytes
md5: 6b0cc492c4d61b3e35b2e8b5bf098450
Time-OlsonTZ-Data-0.201107 is based on version 2011g of the Olson
database. It contains 437 canonical zones and 140
happening, though. DateTime properly
declares its requirement for Module::Build (in META.{yml,json}), and you
apparently have the latest version of the CPAN module, which is meant
to process that declaration. Did you specially configure CPAN to not
follow prerequisites, or something like that?
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201106.tar.gz
size: 226533 bytes
md5: c6593ddf4cb78f20678b62f0fb580180
Time-OlsonTZ-Data-0.201106 is based on version 2011f of the Olson
database. It contains 437 canonical zones and 140
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201105.tar.gz
size: 226396 bytes
md5: 6761aa082b418daae5d7887fb14a5d5d
Time-OlsonTZ-Data-0.201105 is based on version 2011e of the Olson
database. It contains 437 canonical zones and 140
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201104.tar.gz
size: 226216 bytes
md5: 53ee0c64e693ab23d07e1128b2fd6355
Time-OlsonTZ-Data-0.201104 is based on version 2011d of the Olson
database. It contains 437 canonical zones and 140
ndful of effects pushing us in
that direction. Once that happens, you'd want to update T:OTZ:D rather
than DT:TZ.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201103.tar.gz
size: 226188 bytes
md5: a8c6f3f5e3f045414112deba36329e1d
Time-OlsonTZ-Data-0.201103 is based on version 2011c of the Olson
database. It contains 437 canonical zones and 140
odules that you want don't exist yet.
Your best bet is probably to extend DateTime::Format::* yourself, to
optionally generate DateTime::Incomplete objects. Then you can negotiate
about whether your changes should be rolled into the original modules
or should be released separately as DateTime::Incomplete::Format::*.
-zefram
te DT-TZ to use DT-TZ-Olson, at
that point the subject of the volatility policy would change to
Time::OlsonTZ::Data.
-zefram
d just have used out-of-date information
without knowing it.
I suggest that you install the latest DateTime-TimeZone from CPAN (DT-TZ
1.28, based on Olson 2011b), or if you want to use Debian packages then
take the package from testing (1.23, 2010n) or unstable (1.28, 2011b).
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201102.tar.gz
size: 224182 bytes
md5: c11eeb9a6a78633e3f03f4f346a058a2
Time-OlsonTZ-Data-0.201102 is based on version 2011b of the Olson
database. It contains 435 canonical zones and 140
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201101.tar.gz
size: 224113 bytes
md5: b64dd4a2da617401413811d8da724700
Time-OlsonTZ-Data-0.201101 is based on version 2011a of the Olson
database. It contains 434 canonical zones and 140
.
I'm not objecting to the interface, I'm objecting to the semantics.
-zefram
nient way for you to explicitly
attach a particular formatter to each column that you declare. Such as
write a wrapper for the DBIC stuff.
-zefram
Bill Moseley wrote:
>Can the newline be removed? It's not that hard to track down, but it would
>be nice to see where it's coming from.
A useful workaround:
use Carp ();
$SIG{__DIE__} = \&Carp::croak;
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201015.tar.gz
size: 223923 bytes
md5: 3c24d7aae94e0b385f73ea327fa3f85d
Time-OlsonTZ-Data-0.201015 is based on version 2010o of the Olson
database. It contains 434 canonical zones and 140
he Olson timezone database is Asia/Kolkata, and it is also known as
Asia/Calcutta for the obvious historical reason. The Olson database does
not attempt to list all major cities; rather, it picks one representative
for each distinct timezone.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201014.tar.gz
size: 223787 bytes
md5: 80b7d39adf8edec312194cbcffde69bd
Time-OlsonTZ-Data-0.201014 is based on version 2010n of the Olson
database. It contains 434 canonical zones and 140
e, and don't save one here,
so the 1900 offset is just an inconvenience. And historically a lot
of programmers in the 20th century were misled into thinking that the
number was year-AD-modulo-100, which was indeed a source of Y2K bugs.
-zefram
example, never switches at local noon. Beware that some other zones do,
and Helsinki might start doing so at the whim of the Finnish Parliament.
-zefram
Shortly available from all good CPAN mirrors:
file: $CPAN/authors/id/Z/ZE/ZEFRAM/Time-OlsonTZ-Data-0.201013.tar.gz
size: 223836 bytes
md5: 2cbf6db22a1b2dcec4c8bf4d269b0d4a
Time-OlsonTZ-Data-0.201013 is based on version 2010m of the Olson
database. It contains 434 canonical zones and 140
tz->offset_for_datetime($now);
-zefram
# error message is in $@
}
-zefram
Jon Bjornstad wrote:
>How about a class method DateTime->set_default_formatter()
>which would override the default formatter of iso8601()?
That would break any code in other parts of the program that relies on
the default stringification behaviour.
-zefram
Olson database, not a drop-in replacement
for DT:TZ.
If people like DT:TZ:O, we'll then look at changing DT:TZ to use it for
the Olson zones. DT:TZ would of course retain its existing special cases.
-zefram
s, ".", $d->delta_nanoseconds, "\n";
# => 122.456789012
# correctly multiplied up from previous, shows the lost second
There, you've got two outright bugs to be getting on with.
-zefram
s case. %Z is meant for
human use, and should never be used in machine-readable output.
-zefram
egal ISO 8601 representation,
representing the same instant as "2010-02-03T00:00:00Z". Even then,
however, it's not a preferred repreentation for a timestamp.
-zefram
A bug in perl 5.6, some interaction between "use utf8" and regexps,
is causing false test failures for DateTime on 5.6. Attached patch fixes.
-zefram
diff -ur DateTime-0.53.orig/t/13strftime.t DateTime-0.53.mod0/t/13strftime.t
--- DateTime-0.53.orig/t/13strftime.t 2009-12-06 21:14:20
frastructure:
* 14 directories
* 388 filenames for regular files
* 2127 kB apparent total file size
* 388 distinct regular files
* 2127 kB real total file size
* 315 kB compressed tarball of unique files
-zefram
an be distributed via
>CPAN, I think switching to this approach would be fine.
OK, I'll work on it.
-zefram
hem dependencies seems like overkill.
I'm happy to implement more timezone logic on top of DT:TZ:Tzfile, up
to a complete drop-in DT:TZ replacement, but you'll have to argue with
Dave about actually replacing the existing DT:TZ.
-zefram
lename => "/usr/share/zoneinfo/America/Chicago",
);
$dt = DateTime->new(
year => 3, month => 1, day => 1,
time_zone => $zone,
);
-zefram
Nathan Gray wrote:
>I have often thought it would be nice to be able to specify a
>default time zone for DateTime, to use instead of floating.
-1. Action at a distance.
-zefram
CGI::Carp is rude. It globally changes the behaviour of warning and dying
via @SIG{qw(__WARN__ __DIE__)}. You can't expect it to play nicely with
ANYTHING else.
-zefram
behaviour of which is highly variable.
-zefram
gt;today the wrong approach for this application?
Most timezones avoid changing offset at midnight, in order to avoid
this kind of issue. It's handy for midnight to always be well defined.
So is this a bug in Egyptian DST rules?
-zefram
d have been that instant, so the local time jumped
from 2009-04-23T23:59:59+02 to 2009-04-24T01:00:00+03.
-zefram
n.
Try DateTime::TimeZone::SystemV->new("CST3").
-zefram
anything to DT::Span, add a method that
generates the correct SQL expression, taking account of the openness of
each end of the interval.
-zefram
d that intuitive. Your 1 second or 1 nanosecond would
be a completely arbitrary mutation of the supplied data. Whether the
endpoint is included in or excluded from the span needs to be accessible
somehow, but it's not a finite difference in where the endpoint is.
-zefram
27;print
UnixDate("2009-01-01T00:00:00", "%Y-%m-%d %T %z %Z")'
2009-01-01 00:00:00 -0500 EST
$
Timezones aside, those functions are attempting to parse date strings
of unknown format, and hence have unpredictable behaviour. A function
that knows the expected input format will do a much better job.
-zefram
storical reasons
DT::TZ::EST5EDT is implementing "EST5EDT" via an Olson-style observance
listing rather than via DT::TZ::SystemV.
-zefram
e Unix time at 00:00:00 UT on that
day is 86400*14238, and the Unix time at 23:59:59 UT on that day is
86400*14239-1.
-zefram
the rest of the distribution, then checksums will be
computed consistently.
Of course, the principle of signing something other than what's
actually distributed is a stupid idea that opens up security
holes. I have mentioned this to the M::S author, along with the
inconsistent-canonicalisation bug.
-zefram
conds and ->utc_year. Use that class to construct an
object representing the current time. Then call ->offset_for_datetime
on a timezone object, passing in your fake DateTime.
-zefram
Randy J. Ray wrote:
>I get a the timezone as a DateTime::TimeZone::OffsetOnly object. But I'd really
>like the "real" timezone, the one I can get a name or a short-name for.
You can't. They're hopelessly ambiguous.
-zefram
$l = $q->clone)->set_time_zone($zone);
[$l->local_rd_values]->[0] } < $rd;
$p = $q;
}
while(1) {
($q = $p->clone)->subtract(seconds=>1);
last if do { (my $l = $q->clone)->set_time_zone($zone);
[$l->local_rd_values]->[0] } < $rd;
$p = $q;
}
return $p;
}
-zefram
We recently had a thread
<http://www.nntp.perl.org/group/perl.datetime/2008/10/msg7086.html> about
midnight not existing in some timezones, specifically America/Sao_Paulo.
-zefram
actually
do your calculation in UTC. If you really need Sao Paulo time, because
either you need to convert between that and something else or you need
to see the DST effects, construct the DateTime with hour=>12, because
no one switches DST at noon.
This problem, of course, is why *almost* no one switches DST exactly
at midnight.
-zefram
here we can find a usable
| finite() or isfinite() function/macro, so it isn't used on Win32.
Looks like the XS picks up the leap second table from leaptab.txt, but
the pure Perl needs to be edited manually and now isn't being tested by
users who have XS functionality.
-zefram
ng. Many,
presumably, do need (approximate) calculations on times in the future
and before 1972. It is sensible for them that vague-regular-UT is
used in those eras. But they'd be better served by a *consistent*
vague-regular-UT model. No one is well served by the mixed model: it's
vague *ir*regular UT, not guaranteeing any of the useful things that
its component models do. DateTime tries to be everything to everyone,
and suffers from the resulting contradictions.
(Yes, I'm a pedant.)
-zefram
ts from DT::Duration.
Looks like DT::F::Duration is trying to normalise the other way, back
to what you input, but that's going wrong somewhere.
>And if I try and make the pattern => '%e' to just get the number of
>days, this returns 0!
Returns 1 for me.
-zefram
a bad way, especially if the string format is fixed. With
DT::F::Strptime doing its bit, you still need to use the set methods to
copy the time-of-day from one DT object to another (since DT::Incomplete
isn't doing that for you).
-zefram
shares some of the blame, though, for
going through such complicated gyrations with timezones. Using the two
timezones and shifting between them is a definite bug. It looks like it
would work correctly if it just told DateTime to use the local timezone
and didn't ask Date::Manip about timezones at all.
>I suppose I should go look at the internals and submit a patch?
Go patch DT::F::DM, yes. Date::Manip seems to be beyond help.
-zefram
-08-28T10:24:58
1219925098
2008-08-28T12:04:58
$
-zefram
101 - 200 of 288 matches
Mail list logo
