FYI: new leap second on its way
- Forwarded message from <[EMAIL PROTECTED]> - INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 e-mail: [EMAIL PROTECTED] http://hpiers.obspm.fr/eop-pc Paris, 4 July 2005 Bulletin C 30 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 2006 A positive leap second will be introduced at the end of December 2005. The sequence of dates of the UTC second markers will be: 2005 December 31, 23h 59m 59s 2005 December 31, 23h 59m 60s 2006 January 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 1999 January 1, 0h UTC, to 2006 January 1 0h UTC : UTC-TAI = - 32s from 2006 January 1, 0h UTC, until further notice : UTC-TAI = - 33s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Head Earth Orientation Center of IERS Observatoire de Paris, France - End forwarded message -
Re: A datetime comparision question
On Sun, 3 Jul 2005, Albert Whale wrote: I have a function which performs a test on a DB field, and performs an addition of the NOW() + INTERVAL $auth_life_secs SECOND for a Table update. (I do not see this functionality in the DBI - one of the few Use statements in the perl script). This question really has nothing to do with Perl, it's a SQL question. Second, don't send the same message twice. That's just rude. If you didn't get answer it's because nobody knows the answer, nobody wants to answer, or as I mentioned, you're off-topic. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm on a Diet
On Mon, 4 Jul 2005, Daisuke Maki wrote: > I have found DateTime unsuitable to quite a few tasks for > various unfortunate reasons; which is a shame given the level of > following and amount of design time that's gone into it. And I quite agree. It's a shame if we don't fix this and make DateTime.pm useful in any project -- and damnit I want to see it survive in Perl6. Well, I'd take Sam's message with a grain of salt. I use it in lots of projects, and I know it's being used by lots of other people for lots of things. The idea that it's "too slow" is bogus. It might be too slow/bulky if you're creating thousands or hundreds of thousands of objects at once, but even then I wonder if it is. So without anymore adew, here's my braindump of things that needs reviewing, and possible solutions: DateTime.pm - Prioritize features in DateTime.pm, and figure out the most effective area to improve - Use XS, where feasible. Move more existing PurePerl stuff in *PP.pm modules I think most everything that can be XS already is. XS has its own overhead, and if you're just calling lots of Perl functions in XS, particularly OO stuff, it may not be that much faster. I tried rewriting duration addition in XS and it didn't help at all. Locale / TimeZone Given... - Locale and TimeZones are singletons - They are not *that* often used Possible Improvements: - Defer loading them until absolutely necessary That's already done. - Do not keep copy of a these objects in memory, and keep the ID only This would be _slow_. Going to disk every time you need to look up locale or time zone information would be a huge speed hit. - (collary: keep necessary flags like "is_floating" in memory as part of DateTime's blessed hash) This isn't checked all that often. Also implement in XS? Implementing time zones in XS as native C data structures would almost certainly be a huge win. Unfortunately I don't have the C chops for this. Locales are pretty small and I doubt they're a big speed hit. Frankly, I thought Sam's message was a bit hand-wavy. He says: I can see why you'd want to ship a copy of the locale information and timezone database, but IMHO there needs to be a way that these can be coded to be a little more space/file efficient. But it's not clear if he's looked at the locales. They're already pretty tiny, just a few small arrays or hashes for each one. It's not clear how you could make them any smaller, and they're only loaded as needed! Anyway, before people rush off down various paths I'd suggest some profiling and benchmarking, rather than just "making it faster". The first question to answer is what are people doing with these objects? I suspect the biggest benefit would be simply to speed up object creation, rather than the datetime math bits. Secondly, I think slimming down time zones would be a big win (for memory savings), and speeding them up would be nice although not necessarily that noticeable. After that improving datetime math would be good, I think. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
ANNOUNCE: DateTime 0.2901
0.2901 2005-07-04 - A leap second for the end of 2005 was announced. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
DateTime.pm on a Diet
[using my gmail account because for some reason I'm not seeing my mails go through to the list...] Okay, I've been meaning to do this for a while, but now I've just about had enough (plus, now I have some free time). As Sam Vilain wronte in a separete thread: > I have found DateTime unsuitable to quite a few tasks for > various unfortunate reasons; which is a shame given the level of > following and amount of design time that's gone into it. And I quite agree. It's a shame if we don't fix this and make DateTime.pm useful in any project -- and damnit I want to see it survive in Perl6. So without anymore adew, here's my braindump of things that needs reviewing, and possible solutions: Break Down of DateTime.pm: DateTime.pm - Accessors/Mutators - Formatters (ymd, mdy, stringify, etc) - Calculations (day_of_week, week, internal calculations, etc) - Date math (+DateTime::Duration) DateTime-TimeZone DateTime-Locale DateTime-Duration DateTime.pm - Prioritize features in DateTime.pm, and figure out the most effective area to improve - Use XS, where feasible. Move more existing PurePerl stuff in *PP.pm modules Locale / TimeZone Given... - Locale and TimeZones are singletons - They are not *that* often used Possible Improvements: - Defer loading them until absolutely necessary - Do not keep copy of a these objects in memory, and keep the ID only - (collary: keep necessary flags like "is_floating" in memory as part of DateTime's blessed hash) Also implement in XS? If you guys have any suggestions, critiques, or anything else, please let the list know. For one, I'm going to see where I can just go ahead and switch to XS and send a patch... Let's make this excellent framework leaner and meaner! --d
Re: Perl 6 DateTime
Dave Rolsky wrote:
I may have been quite vocal in the past about the practical failings
of DateTime for Perl 5, but as I'm sure we both know, the API has needed
Actually, I don't remember you saying anything, but maybe it was a while
back on the datetime list?
Possibly. I have found DateTime unsuitable to quite a few tasks for
various unfortunate reasons; which is a shame given the level of following
and amount of design time that's gone into it.
For instance, the in-memory objects are quite heavy, especially compared to
Class::Date, or a simple ISO representation as used by Date::Manip. I can
see why you'd want to ship a copy of the locale information and timezone
database, but IMHO there needs to be a way that these can be coded to be a
little more space/file efficient. Adding a parser for a new format was easy
enough, but the performance at the end of it was noticably slower than other
modules.
But of course these are all implementation problems so nothing to do with
what I grok DateTime is about ;)
Well, I think what you started already has some serious mistakes. For
one, the Huffman coding is backwards. You've used "Date" for a generic
interface, which is something that only calendar authors need to
implement, and then used Date::Gregorian for the thing that will be used
all the time. Short names like "Date" or "DateTime" should go to the
most commonly used bits, which is the Gregorian implementation.
Interfaces should have long names, like "Date::Calendar::Interface".
That is true, but I think it is also very important that you can use;
if ($item.does(Date)) {
}
And not have to worry about whether you're running on a system that uses
the Gregorian calendar as primary or not. That might seem like an odd
requirement, but I see large sections of the world being forced to use the
relatively useless Solar calendar because of our society's inflexibility,
and it would be nice if we didn't need to force that. Also how are aliens
supposed to write code in Perl 6 if we force them to constantly marshall
their non-linear time bases into our reference frame? We cannot overlook
people living in regions where time requires junctions to be expressed.
In terms of Huffmanisation, I'd also like to see this sort of thing work;
use Date;
my $date = date(time());
And have the Date module find the preferred date module that you want to
use and present that. If your code actually uses Gregorian-style accessors,
then you would want to use Date::Gregorian instead to imply that dependency.
No doubt, there will be a coerce method supplied;
multi sub coerce:( Date $from, Date::Gregorian $to ) { ... }
(something like that - see autrijus' recent journal entry)
So that when you specify that a function requires the Date::Gregorian
interface, or a DateTime interface, or whatever, then it can silently
and transparently cast it.
I also am not big on exporting functions like "date()" by default. I
think that's useful, but it definitely be on request.
I used to be like this, too. Then ingy suggested to me that I add a set()
constructor to Set::Object, exported by default, and I haven't looked back.
Also, I'm not sure how far specced the export traits are, or how far
implemented.
Exporting by default is normally reserved only for the most useful
functions; such as YAML.pm exports Load and Dump but not LoadFile and
DumpFile. If words clash, you can always provide a null export list, but
if you Get It Right™, then the users of the module will just love it! :)
Anyway, I think there's lots of time to play with this. I think you
should feel free to continue working on your code too, since there's no
need to have a unified effort at this time. If you'd prefer to work
together, that's fine too.
Ok, well what I was aiming for was a unified "Date" role - abstract from
the implementation - so that authors of date code can fairly transparently
switch between implementations, if their usage is sufficiently basic.
At the very least, we can probably share parts of each other's test
suites so that both of our implementations are of high quality and we can
learn from each other's experiments.
The really cool thing about developing Perl6 for Pugs at the moment is
that there's no way anyone can use it in production, so we're free to
break backwards compatibility at the drop of a hat ;)
Yes, very true :-).
- Explore a new DateTime API - right now I'm inclined to start with 3
core classes - Date, DateTime, and DateTimeTZ. DateTime would be a
datetime in the floating time zone, while DateTimeTZ would have a real
tz. I'm also thinking of trying to create a Time class, so that
DateTime is simply a container of a Date and a Time. The advantage here
is that authors of calendar modules which have the same 24-hour time
system can reuse that. Probably we'd need Time and TimeLS (leap second)
or something like that.
ok. I think I get what you mean - there's a lot of clock related code
A datetime comparision question
I have a function which performs a test on a DB field, and performs an
addition of the NOW() + INTERVAL $auth_life_secs SECOND for a Table
update. (I do not see this functionality in the DBI - one of the few
Use statements in the perl script).
I would like to set a variable equal to this amount so that I
can test the value of the DB Field to see if the update should be performed.
I want to modify the update to only update the field if the
record_expires field is less than the quantity of NOW() + INTERVAL.
my $rows = $dbh->do("UPDATE table SET record_expires = NOW() + INTERVAL
$auth_life_secs SECOND, last_update=current_timestamp"
I need to modify the Select statement to ignore records which have a
record_expires field which is past the quantity of DATE() + INTERVAL.
How can I test the value of the record_expires field?
--
Albert E. Whale, CHS CISA CISSP
Sr. Security, Network, Risk Assessment and Systems Consultant
---
ABS Computer Technology, Inc. - www.ABS-CompTech.com
SPAM Zapper - No-JunkMail.com - Spam-Zapper.com - SPAM Stops Here.
President of the Pittsburgh InfraGard Alliance
Please Ignore, This is a Test
Some of my mails to datetime@perl.org seem to have vanished before reaching the mail list... this is just a test. please ignore.
