I'm not sure how many of you subscribe to MJD's Perl
Quiz-of-the-week, but this week it concerns datetime and what he
calls 'Greek Time'. Basically midnight = midnight and noon = noon.
However 6pm (greek) = sunset. This means that night hours are longer
in winter and day hours are longer in
, not extended formats. The
extended formats are something else. For instance, 2003-06-19
is an extended format, but 20030619 isn't.
-YYMM Year and month in implied century
-DDDOrdinal day in implied year
-YY Year in implied century
+y Extended year
+yYY
Peter J. Acklam wrote:
Iain Truskett [EMAIL PROTECTED] wrote:
Unix epochs are always GMT/UTC based (one of the two).
Perl's gmtime() and localtime() aren't UTC compatible.
I'd say they are using TAI time. GMT belongs to the past.
Except you'd be wrong. ;~)
GMT == UTC for all intents and
John Peacock [EMAIL PROTECTED] wrote:
Peter J. Acklam wrote:
Perl's gmtime() and localtime() aren't UTC compatible.
I'd say they are using TAI time. GMT belongs to the past.
Except you'd be wrong. ;~)
Conveniently for me, the pages you quote back me up, not you.
GMT == UTC for all
On Thursday, June 19, 2003 Jerry Wilcox wrote:
At 4:25 PM +0200 6/19/03, Peter J. Acklam wrote:
Anyway, I see your point, but I don't agree. There is only need
for an agreement when ambiguous formats are used, which is a good
thing since ambiguous date formats are, as everyone here knows, a
big
Peter J. Acklam wrote:
Conveniently for me, the pages you quote back me up, not you.
I should have been more explicit in what I was asserting, then. The colloquial
term GMT has been supplanted by the functionally equivalent, and much more
accurately defined, UTC as the source of international
Peter J. Acklam schreef:
And you say that Perl is usually using UTC. Then please show me
some examples of Perl giving the following, which would be correct
for an UTC clock. Actually, just one example would be nice.
$ perl -wle 'print scalar gmtime $_ for 78796799 .. 78796801'
Fri
Rick Measham schreef:
In his question, he assumes that each period (night/day) should be
evenly divided into 12 parts. However this stinks to me! Surely in
the middle of winter, the hour before sunrise shouldn't be a heap
longer than the hour after? Surely the lengths of hours should slowly
Well that was always my intention. I plan to allow the caller to
specify what exact rules to use since the spec basically allows very
little unless the parties agree.
However, I think that the default format (if nothing was specified)
should allow for parsing of common ISO8601 formats.
This
I am running the CVS versions of DateTime/DateTime-TimeZone for perl 5.6.1
Hi Ron,
I don't claim to know anything about perl on win32 but I'm wondering if there is any
difference in warnings under 5.8.0. Is it possible for you try this?
-J
--
It looks like the Jalali calendar is also called the Persian calendar,
so DateTime::Calendar::Persian is a possibility too. I'm not familiar
with this calendar, its most common name, and the way it is used, so you
(Ahmad) should judge for yourself what name would be best.
In Calendrical
John Peacock [EMAIL PROTECTED] wrote:
Peter J. Acklam wrote:
I didn't mean that Perl is using a TAI library, but the TAI
time system or TAI calendar.
Perl is _not_ using TAI, since it is employing an epoch
corresponding to the Unix epoch (except on Mac's???).
I don't see what the epoch
Eugene van der Pijll [EMAIL PROTECTED] wrote:
If Perl (or the underlying library functions) used TAI, it
should have printed something like
$ perl -wle 'print scalar localtime $_ for 78796799 .. 78796801'
Sat Jul 1 01:00:09 1972
Sat Jul 1 01:00:10 1972
Sat Jul 1 01:00:11
John Peacock [EMAIL PROTECTED] wrote:
When I made a very simple attempt at this back in January, I limited myself to
the most basic format:
if ( @date =
( $val =~ /(\d\d\d\d) # year with century
-? # possible hyphen
(\d\d)
John Peacock schreef:
Peter J. Acklam wrote:
I don't see what the epoch has got to do with it. The TAI time
system is exactly like UTC except for the leap seconds, and that,
to me, seems very similar to what Perl is using.
The epoch has everything to do with it. TAI is not defined to
Ahmad Anvari schreef:
I would suggest registering DateTime::Calendar::Jalali
for now.
If that's what most potential users would recognize, it's the right
name. I wouldn't have recognized it, but I'm not the intended audience.
(But I'll install it anyway...)
Eugene
On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote:
[...]
When I started writing DateTime::Format::ISO8601 I was using the ordering method.
Although I think it maybe necessary to to use both 1 and 2. Someday I may finish
this module - what name are you planning on using?
I
I put these on datetime.perl.org. They're linked from the resources page.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Well, while I was at YAPC my server crashed over and over. Whee! So I
may have missed email. If there was something that someone wanted me to
respond to, and I don't do so by next Monday or so, please let me know
about it.
-dave
/*===
House Absolute Consulting
I don't know if I will manage to finish this thing, it is a bit of a
monster.
Thats what happened to me. :)
-J
--
This fails on both 5.00503 and 5.6.1.
For 5.6.1, installing the latest Math::BigInt from CPAN fixes this, but
unfortunately the latest distro has a missing file that causes it not to
pass its tests.
On 5.00503, other Math::BigInt tests fail which seems to just be a
backwards compat problem.
21 matches
Mail list logo
