, which implements the ISO 8601 calendrs in
terms of Chronological Julian Day Numbers. They can be found at
http://search.cpan.org/~zefram/. Thanks.
-zefram
of time-of-day with a calendar module.
-zefram
rather than unadulterated UTC.)
-zefram
to make them all interoperate nicely.
-zefram
this model of MJD.
The other way to derive a JD from UTC is to use UTC-SLS
http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/, which changes rate for
the last 1000 s of a UTC day. I wrote a module which implements this.
-zefram
misunderstanding it?
my hobby is genealogy, and I'm already happy if I
get the year right. ;-)
Heh. That's tricky enough, for the Middle Ages, with so many competing
dates to start the year.
-zefram
gets this right.
Since, as I said, it's a slightly ill-defined concept anyway, right
is not so much any particular behaviour, but rather documenting exactly
what you do. Anything that mixes JD and UTC really needs to document
how it maps between them.
-zefram
time_t then that's how
it works.
-zefram
, and particularly a clear concept of what an
object represents. So I think it'd be good if we could come up with
sentences starting An object of this type represents ... to go at the
top of each class's documentation.
-zefram
list was strictly concerned with DateTime and its existing architecture,
rather than with date/time issues in general. I got pointed here from
the modules mailing list, when I tried to register Date::JD.
-zefram
. Looks like he wants to store a time of week, timezone-relative,
along with a timezone spec. The incrementing loop he came in with is
just answering the question when will that time of week next occur?.
-zefram
, second. Any application that needs
to accept different element sequences needs to look at the prefix and
separators.
-zefram
, not policy.
-zefram
that it looks up the current
time each time round:
while(1) {
my $dt = DateTime-from_epoch( epoch = time() );
my $time = $dt-strftime( '%Y-%m-%d %H:%M:%S.%3N' );
print $time\n;
}
-zefram
one described in Calendrical Calculations.
So I was planning on using the following namespaces:
...
Does this seem ok?
Looks good to me.
-zefram
Jaldhar H. Vyas wrote:
Unfortunately the one described there doesn't really match up to anyone
used in real life.
Not all that surprising. I found an awful lot of errors in that book
on the stuff that I know about.
-zefram
Aravind J wrote:
Do we have any patch for the Perl Date Time module for new Daylight
Savings Times (DST) changes in 2007 as per Energy Policy Act of 2005
The latest DateTime::TimeZone, version 0.57, reflects this change.
-zefram
2005?
Since version 0.38, released 2005-11-21.
-zefram
to upgrade anyway.
-zefram
/src/DROLSKY/DateTime-TimeZone-0.58/Changes,
which said that 2005n went into 0.38.
-zefram
on version 2005l.
Anyway, for your FAQ: based on brief examination of the module files,
the first released version of DT::TZ that has the 2007+ US rule is 0.37,
dated 2005-08-22.
-zefram
($next_y, $next_w, $repeat_dow)), \n;
I expect the same algorithm can be implemented using DateTime, but I'm
not a regular user of that, sorry.
-zefram
'use DateTime;print DateTime-now(time_zone = local)-hms()';
-zefram
if you've made it this far through this message.
My experimental code is at
http://www.fysh.org/~zefram/time/purchron
For a multi-scale display, do
$ purchron
'(fixed,UTC:)_(ymdhms,UTC,9,-1)/___(fixed,GPST:)_(ymdhms,GPST,9,-1)/(fixed,TAI:)_(ymdhms,TAI,9,-1)/(fixed,TT%28TAI%29:)_(ymdhms
all the real-time
stuff goes, though I might make another library out of that some day.
-zefram
if the
generic offset capability is implemented: you can always do LMT as a
UT1+... spec.
-zefram
) there.
-zefram
. But since handling the IERS
forecasts alone is much simpler than the full UT1 module, I might do
the IERS bit on its own in purchron first.
-zefram
and constructor argument. Interpreting POSIX timezone strings might be
a good application of this idea.
-zefram
are applicable to any use of the 24-hour clock.
-zefram
zoneinfo
database contains all currently-distinct timezones. (It explicitly aims
to include all timezones that have been distinct at any time since 1970.)
You might want to play with the tzselect(8) program, which guides one
through selecting a geographical timezone from the database.
-zefram
I've knocked together an implementation of SysV/POSIX
timezone specifications for DateTime. Code is at
http://www.fysh.org/~zefram/tmp/SystemV.pm. This is my first go at
implementing anything in the guts of DT, so experts here please check
that I'm using the interfaces correctly. I don't quite
I wrote:
I've knocked together an implementation of SysV/POSIX
timezone specifications for DateTime. Code is at
http://www.fysh.org/~zefram/tmp/SystemV.pm.
No comments from anyone, and only two people have downloaded the code.
I presume, then, that those who looked at the code were happy
be accepted and ignored, for compatibility with the
libcs that accept it for some syntaxes.
-zefram
I wrote:
I'm also now working on a tzfile(5) reader in DT::TZ form.
Trial code is at http://www.fysh.org/~zefram/tmp/Tzfile.pm.
If there are no objections, I'll put DT::TZ::SystemV on CPAN at the
coming weekend, and DT::TZ::Tzfile the next weekend.
-zefram
DateTime::TimeZone::SystemV is now on CPAN.
-zefram
: std,
)\n;
}
-zefram
DateTime::TimeZone::Tzfile is now on CPAN.
-zefram
) are thrown
away. Little difference in behaviour, but internally cleaner. Now no
single-part Olson zone names are used as such.
The documentation about name parsing is now more accurate.
-zefram
I wrote:
Attached is a patch that revises timezone name parsing in DT::TZ.
Except that I forgot to attach it. D'oh. Really attached this time.
After applying the patch you'll need to do a ./tools/parse_olson --clean.
-zefram
diff -ur dttz-0.59/Build.PL dttz-mod0/Build.PL
--- dttz-0.59
I've published some code at
http://www.fysh.org/~zefram/time/time_scale_expt
which is where I am with regard to processing diverse time scales.
I'll do something akin to that in purchron when it's all settled, and
I'd like to do something similar in non-real-time Perl modules too.
Comments
respects it's equivalent to the previous patch. As before
you'll need to rerun tools/parse_olson, to pick up the changes to
TimeZoneCatalog.pm.
-zefram
diff -ur dttz-0.6101/lib/DateTime/TimeZone/Local.pm
dttz-mod1/lib/DateTime/TimeZone/Local.pm
--- dttz-0.6101/lib/DateTime/TimeZone/Local.pm 2007
Bonus patch: this adds handling of the nautical single-letter timezone
names to DT::TZ::OffsetOnly and DT::TZ. Very simple feature, bound to
be useful to someone.
-zefram
diff -ur dttz-mod1/lib/DateTime/TimeZone/OffsetOnly.pm
dttz-mod2/lib/DateTime/TimeZone/OffsetOnly.pm
--- dttz-mod1/lib
all $TZ settings that the
various libcs do. System V strings are an important subcase.
-zefram
I wrote:
http://www.fysh.org/~zefram/time/time_scale_expt
Version 0.001 is up. This release does Martian time, including
the timezones used by the rover missions. (Martian rotation is much
easier to model than Terran, because Mars has no large moon, tectonics,
or oceans, all of which make
,
then the current observance is the one starting at that instance.
If an observance stretches infinitely far into the past or future,
Cundef is returned for any non-existent boundary.
I'll do a patch to implement this if no one objects.
-zefram
Dave Rolsky wrote:
- This release is based on version 2007c of the Olson database.
Where do we stand regarding my proposed changes? Are you waiting for
anything from me?
-zefram
not make it available.
Quite.
-zefram
and so
are memorable.
If you want three names, how about
prev_observance_start_for_datetime
this_observance_start_for_datetime
next_observance_start_for_datetime
-zefram
that fails if given a date that is exactly
a boundary. The three method way puts the effort where it belongs: in
the library, where it's actually easier to implement than the two methods.
-zefram
an arbitrary DT, if you happen to know that your
timezone fits the twice-yearly-change pattern, you can do next from
the start of the year or previous from the end of the year to find the
two boundaries.
-zefram
observance. And this_transition
is meaningless. If you want to drop the _for_datetime bit then just
go to {prev,this,next}_observance_start: it is the observance, not
the transition, that is the referent of this and the others.
-zefram
go the route of a separate heavyweight
mechanism, with a very lightweight mechanism in the classes themselves,
then there may be an advantage in keeping the interface (and unavoidable
implementation structure) as small as possible.
-zefram
-01-14T16:00:00 CST
+9weeks cen: 1174251600 - 2007-03-18T16:00:00 CDT
+9weeks GMT: 1174251600 - 2007-03-18T21:00:00 UTC
-zefram
of
their actual timezone. You can handle both cases, therefore, with just
the local timezone logic.
-zefram
at best you'd expect to get a list of matching
timezones. The timezones aren't indexed in this way, so you'd have to
iterate through the lot checking each. DateTime::TimeZone-all_names
provides the list that you'll need to check through.
-zefram
is expected, it is unambiguous
and so parsing it this way is acceptable.
-zefram
of this event (which may both be
infinite).
A recurring event is not a single event. It is a structured group of
events. You should have distinct classes for single event and recurrence.
Most of the methods you list are applicable to one class or the other,
not both.
-zefram
.
On the contrary, it is of the most profound conceptual importance.
-zefram
settings in your
dumps of the DateTime objects.
Neither of these timezone settings is what you want. You most likely
want to use your local timezone in both cases. Try adding the parameters
time_zone = 'local' in both constructor calls.
-zefram
);
-zefram
is supposed to be an integer, and
it would be better to avoid floating-point arithmetic entirely:
$fraction = substr($fraction, 0, 9);
$fraction .= 0 x (9 - length($fraction);
$p{'nanosecond'} = 0 + $fraction;
-zefram
multiples
of five minutes, so I presume there's some rounding going on there,
but I'm at a loss to determine whether the rounding performed was down
or to nearest. There's not much concern for precise timing in evidence.
-zefram
,
unfortunately.
-zefram
days. To get the duration expressed purely in days,
do $dur-in_units(days).
-zefram
referenced by $day1, and leave the original date/time variable,
the one referenced by $date1, alone.
-zefram
Dave Rolsky wrote:
is one major change in this release, for the new Venezuelan time
zone.
What, again? I thought he'd've learned the first time.
-zefram
http://www.willbell.com/math/mc1.htm. Google
for equinox calculation to find several lower-precision algorithms in
various programming languages.
-zefram
that your comparison predicates should be either standalone
functions (for which the module name DateTime::Span::Compare is an
excellent choice) or additional methods in the DateTime::Span class.
I think the former is the most sensible interface.
-zefram
for everyone else.
I note that EST, MST
and HST are supported timezones:
Historical oddities. Not role models.
-zefram
);print time;print DateTime-now'
1219919095
2008-08-28T10:24:55
1219925095
2008-08-28T10:24:55
$ perl -MTest::MockTime=:all -MDateTime -lwe 'print time;print
DateTime-now;set_relative_time(6000);print time;print DateTime-now'
1219919098
2008-08-28T10:24:58
1219925098
2008-08-28T12:04:58
$
-zefram
::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
to
copy the time-of-day from one DT object to another (since DT::Incomplete
isn't doing that for you).
-zefram
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
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
/msg7086.html about
midnight not existing in some timezones, specifically America/Sao_Paulo.
-zefram
);
last if do { (my $l = $q-clone)-set_time_zone($zone);
[$l-local_rd_values]-[0] } $rd;
$p = $q;
}
return $p;
}
-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
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
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
: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
listing rather than via DT::TZ::SystemV.
-zefram
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
, add a method that
generates the correct SQL expression, taking account of the openness of
each end of the interval.
-zefram
).
-zefram
jumped
from 2009-04-23T23:59:59+02 to 2009-04-24T01:00:00+03.
-zefram
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
variable.
-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
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
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
be fine.
OK, I'll work on it.
-zefram
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
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.0
be a legal 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
is meant for
human use, and should never be used in machine-readable output.
-zefram
lost the half that needs to carry into the ns
$d *= 2;
print $d-delta_seconds, ., $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
it for
the Olson zones. DT:TZ would of course retain its existing special cases.
-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
is in $@
}
-zefram
1 - 100 of 242 matches
Mail list logo
