On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
DT::TZ::LINKS is still the only internal structure that is modified.
Yes, but you access @DT::TZ::ALL as well.
almost certainly does not belong in a module called Alias! Why does
it
Probably not - but what ever module handles the aliasing
On Sat, 21 Jun 2003, Bruce Van Allen wrote:
One thought: A fiscal year is type of calendar, and as the (long-ago)
DT consensus was that all calendars are adopted fictions, perhaps it
should be DT::Calendar::FiscalYear. The API would have to be somewhat
different from the existing DT::C
Ben Bennett [EMAIL PROTECTED] schrieb/wrote:
There is a related question about what I should _really_ be returning
for the reduced formats. For example, the format matches a year,
right now I return Jan 1st of the year, or YY gives a century, so if
given 20 I return Jan 1st, 2000. Does
Dave Rolsky schreef:
Here's the thing. Yes, the object would contain more precision than the
original data, _but_ presumably if you are only exchanging year and
month data, then you will only look at the year and month of the returned
object.
It's really hard for me to think of a case
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.01.tar.gz
This is the code I'm expecting to become DT::F::ISO8601::Simple or the the like.
supports all the ISO8601 date, time, and date + time formats
expanded formats are support with a fixed 6 digit year
Please see
I forgot to add that it's dependant on the CVS version of DT.
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.01.tar.gz
This is the code I'm expecting to become DT::F::ISO8601::Simple or the the like.
supports all the ISO8601
Dave Rolsky schreef:
It's really hard for me to think of a case where you would not know the
expected precision in advance.
It's usually true that you do know the precision in advance (not always) but not ALL
handling of time involves knowing the year.
On Sun, 22 Jun 2003, Eugene van der
On Sun, Jun 22, 2003 at 04:47:42AM +0200, Eugene van der Pijll wrote:
If YY really is the century, you should probably return Jan 1st, 1901
when given 20...
The example given in the spec says that given 12 April 1985 YY gives
19. So they are being a little loose with the word century...
OK , I am coding up the port from Date::Calc::Fiscal right now. I should
have something for y'all to look at by the end of the day ( I hope ). I
will still have to write docs and test. It will have only 2 methods right
now, day_fiscal_year - if Mar 1 is fiscal start, then Mar 1 is day 1 not
59;
I used to live in Saudi Arabia and the weekend was on Thursday and
Friday (I don't know what calendar businesses used but I will ask my
father).
-ben
On Sun, Jun 22, 2003 at 01:37:24AM -0500, Dave Rolsky wrote:
On Sun, 22 Jun 2003, Eugene van der Pijll wrote:
Dave Rolsky [EMAIL PROTECTED] wrote:
On Fri, 20 Jun 2003, Eugene van der Pijll wrote:
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
On Sunday, June 22, 2003 Dave Rolsky wrote:
On Sat, 21 Jun 2003, Bruce Van Allen wrote:
The point of DT::Format::XXX is parsing and formatting:
- to return a DT object if given an XXX-formatted date/time string; and
- to return an XXX-formatted string from a DT object.
Well, the formats can
On Sunday, June 22, 2003 Eugene van der Pijll wrote:
Bruce Van Allen schreef:
From a string in the form MM, the DT::F::ISO8601 parser
should return a DT object identical to the DateTime object
instantiated from
$dt = DateTime-new(
year = 2003,
month = 6.
);
On Sunday, June 22, 2003 Jesse Shy wrote:
OK, I am coding up the port from Date::Calc::Fiscal right now.
Yay. The DT project advances into a new continent of usefulness!
It will have only 2 methods right now, day_fiscal_year - if Mar 1 is
fiscal start, then Mar 1 is day 1 not 59;
Peter J. Acklam schreef:
It is the IERS (http://www.iers.org) who decides when leap seconds
are inserted. According to their page
http://www.iers.org/iers/earth/rotation/utc/table1.html
the first leap second after 1970 was the second before 1972-07-01
00:00:00 UTC.
There cannot have
On Sun, 22 Jun 2003, Ben Bennett wrote:
I used to live in Saudi Arabia and the weekend was on Thursday and
Friday (I don't know what calendar businesses used but I will ask my
father).
If it was on Thursday and Friday it was still following the Gregorian
calendar though. That was my basic
http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.
html
... Since the system was introduced in 1972,
The table starts in 1972. Before that, GMT was
in use - not UT1!
- Flavio S. Glock
So the first shot is at http://www2.pona.net/~jshy/DTFY.tar.gz
Its 2 files, one is the module the other is a small test program. I will
actually write some tests starting this week. I know there are bugs on
the fringe dates, that is the first and last day of the year. We'll throw
this against the
Eugene van der Pijll [EMAIL PROTECTED] wrote:
Peter J. Acklam schreef:
It is the IERS (http://www.iers.org) who decides when leap
seconds are inserted. According to their page
http://www.iers.org/iers/earth/rotation/utc/table1.html
the first leap second after 1970 was the
John Peacock [EMAIL PROTECTED] wrote:
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
Jesse Shy [EMAIL PROTECTED] schrieb/wrote:
OK , I am coding up the port from Date::Calc::Fiscal right now. I should
have something for y'all to look at by the end of the day ( I hope ). I
will still have to write docs and test.
I see two problems with the name:
* it introduces two new levels,
http://mysite.freeserve.com/ridas/download/ridas/datetime/locales/locale20030622.tgz
Changes:
* Added new locale generator (ICUGenerator.pl) which is not derived from my
other work - this is largely untested. Locale data is not supplied and must
be generated from ICU .xml sources.
* All
I understand your point, however, this is not a calendar and does not
produce one yet. Sure I would like to have it create a calendar where you
say my fiscal year starts 03-01 and I have 13 periods and it produces a
calendar view of the year with 13 periods of 28 days, so Mar 29 - 31
appeared in
Should I add the namespaces doc to web/htdocs/developer/?
-J
--
On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
Should I add the namespaces doc to web/htdocs/developer/?
Sure, please do.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sun, 22 Jun 2003, Dave Rolsky wrote:
On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
Should I add the namespaces doc to web/htdocs/developer/?
Sure, please do.
BTW, you should use Pod::Simple::HTML for the conversion, not pod2html
that comes with Perl. The latter produces really icky output
On Sun, 22 Jun 2003, Richard Evans wrote:
* Added new locale generator (ICUGenerator.pl) which is not derived from my
other work - this is largely untested. Locale data is not supplied and must
be generated from ICU .xml sources.
Thanks, this looks great.
* All manually edited code removed
Check out Dave's work on the POD to HTML stuff for the FAQ for a
start...
-ben
On Sun, Jun 22, 2003 at 06:41:16PM -0500, Dave Rolsky wrote:
On Sun, 22 Jun 2003, Dave Rolsky wrote:
On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
Should I add the namespaces doc to
Fantastic! Thank you for the summary, I will add it to the FAQ (with
appropriate attribution of course).
-ben
On Sun, Jun 22, 2003 at 10:36:02PM +, [EMAIL PROTECTED] wrote:
Thanks Eugene.
I'll try to rephrase this, because it
would be good to have it in the
On Sun, 22 Jun 2003, Ben Bennett wrote:
Check out Dave's work on the POD to HTML stuff for the FAQ for a
start...
Actually, the FAQ is much more complicated. For the other docs I've just
been doing
perl -MPod::Simple::HTML -e \
Pod::Simple::HTML-filter(shift) \
pod file
and then
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
DT::TZ::LINKS is still the only internal structure that is modified.
Yes, but you access @DT::TZ::ALL as well.
I was necessary to verify that what an alias was pointing to was valid.
Once the dependency was already there I implemented the rest.
31 matches
Mail list logo
