> > I was thinking about DateTime::Format::ISO8601... unless you have laid
> > claim to it.
This is the namespace I started on in March but whatever does ISO8601 should go there.
> Perhaps one of you should add it to the CVS server as-is and both work
> on it?
I haven't worked on this since the
> I put these on datetime.perl.org. They're linked from the resources page.
This is a great primer to some of the issues in time handling. It'd make an
interesting talk even with out all the bits about programming.
Btw - Is anyone headed to OSCON?
-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. Ugh.
> 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
--
* Ben Bennett ([EMAIL PROTECTED]) [20 Jun 2003 12:59]:
> 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 fi
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
www.houseabs
I put these on datetime.perl.org. They're linked from the resources page.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
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
> 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...)
We could also put in a
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
> That's why I can't tell what the correct name would be for this
> calendar, (and why you can't either, I presume). Ahmad is hopefully more
> familiar with how the calendar is used today.
It's important that it's name is meaningful to potential users. We'll just document
that we decided Jalali,
Joshua Hoblitt schreef:
> > 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 w
Rick Measham schreef:
> Sorry, I should have said that I wasn't interested in the historical
> context for this, only in the mathmatics behind it. I realised that
> historically they wouldn't have done what I was suggesting, but as
> you say, for us computer owning people it would be nice.
In t
Hi everyone
http://mysite.freeserve.com/ridas/download/ridas/datetime/locales/locale20030619.tgz
Lot of changes here (better for you Joshua? :), so please give it a good
test run and see what you think.
Look at example.pl to get an idea of how things work - you could read the
docs, but they're a
Peter J. Acklam schreef:
> I could have sworn the difference was 0 seconds between 1970-01-01
> and until the leap second in June 1972. I should have checked
>
> ftp://maia.usno.navy.mil/ser7/tai-utc.dat
By the way, according to the formulae on this page, TAI-UTC was 9.89
seconds on 1971-12-31
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
Peter J. Acklam wrote:
That's too general, actually. There must be a hyphen either both
places or none of them. The above matches "2003-0619" and
"200306-19". :-)
Something like this should do the trick (untested)
(\d\d\d\d) # year with century
(-?)
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 start with 0 at
Jan 1, 1970 (Unix
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
>
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
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
> 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 Ca
> 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
--
Ben Bennett wrote:
However, I think that the default format (if nothing was specified)
should allow for parsing of common ISO8601 formats.
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
F:\perl_modules\DateTime-Format-Strptime-1.02>nmake test
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
F:\perl\bin\Perl.exe -Mblib -IF:\Perl\lib -IF:\Perl\lib -e "use
Test::Harness qw(&runtests
verbose); $verbo
> So you could also define an hour as 1/12th of the day, and accept that
> a day isn't 24 hours exactly. But who cares, noone stayed up the whole
> night then. ^
I'm happily entertaining myself, imagining that you were deliberately making
puns around 'noon', 'n
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 need
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 slo
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'
>
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 internationa
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,
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 pain in the butt.
Those who wrote the standard co
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 f
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 purp
ar
No, these are called "expanded", 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
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 sum
Hi Dave,
I noticed that the fractional_second method is still in CVS. Is this going to be
dropped as well?
I took a look at changing utc_rd_values to support nanoseconds and it doesn't look
like much needs to be changed.
Calling _normalize_nanoseconds in the contructor certainly makes life ea
37 matches
Mail list logo
