All you astro people (and math freaks)
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 summer. 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 decrease towards noon and then increase again towards midnight. I figured this is a sine wave. However when I thought about it I realised it wasn't. But what is the conversion? At the equinoxes, it (should) be a straight line graph. However as sunrise gets later, it becomes a half-sine-wave. The skew based on sunrise/set times. The question is this: How does one turn a sine wave into a straight line slowly? There must be a mathematical function that allows us to create a formula to get the 'percentage of daylight' at any point in the day. (I'm not talking observed daylight but some theoretical daylight that puts 50% at sunrise and set) Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
RE: ISO 8601 is eeeevil!
Ben Bennett [EMAIL PROTECTED] wrote: Ok. So ISO8601:2000 defines all sorts of things, some of which are impossible to distinguish from one another without outside information: +yMMDD Extended complete year +yDDD Extended ordinal day in year 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 -YY Year in implied century +y Extended year +yYYExcended century Again, the formats you call extended formats are expanded, not extended formats. Notation: -: - Character Y,M,D: Year, month, day digit respectively +: + or - characters The root of the collisions is the arbitrary number of extended digits (which may be 0, so you could have -0101, now is that the year 102 BC, or January in 2001? The extended formats also collide internally, i.e. what is the date +1985? Is it a century or a year? There is no collision. The standard clearly states that expanded formats should only be used when there is a mutual agreement by the partners using the formats. Implied: The agreement should contain the information necessary to disambiguate. If there is no agreement on what the format is, then you should assume that expanded formats are not used. And you still don't get the difference between expanded and extended formats. The choices for resolving this are to: 1) Never allow an extended representation (even for +s which can't collide externally) unless the user tells us to use it and specifies the digits 2) Use the ordering above to break ties I am leaning towards choice 2 for this, but things are not completely dire since I plan to allow the user of the module to pick which categories of formats to allow (and to specify how many digits are in an extended date). You shouldn't implement anything related to ISO 8601 until you have read and understood the standard. The standard clearly states that you should use 1) since expanded formats should not be used unless there is an agreement to use them. Peter -- Peter J. Acklam - [EMAIL PROTECTED] - http://home.online.no/~pjacklam
Re: Getting different results from DateTime and Manip for epoch time
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 purposes: http://www.wikipedia.org/wiki/Coordinated_Universal_Time http://www.webreference.com/js/tips/010929.html Perl is not using TAI, but rather the underlying O/S epoch (which usually means UTC). There is some discussion of using Dan Bernstein's libtai as a basis for time values in Perl6, but I don't think that has been settled yet. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: Getting different results from DateTime and Manip for epoch time
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 intents and purposes: UTC and GMT are different in several aspects. The definition of UTC is different than that of GMT, and UTC has leap seconds whereas GMT doesn't. http://www.wikipedia.org/wiki/Coordinated_Universal_Time That page says UTC bases time measurement on atomic standards rather than GMT's celestial ones. so UTC is not GMT. http://www.webreference.com/js/tips/010929.html That page says UTC isn't the same as GMT (proper GMT was originally measured from Greenwich mean mid-day, not mid-night [proof: Astronomical Almanacs 1984 onwards, page B5]), as UTC is an ATOMIC time-scale, while GMT (strictly speaking UT1 [UT-one]) is tied to the rotation of the Earth in respect to the fictitious 'mean Sun'. again showing that GMT is not UTC. Perl is not using TAI, but rather the underlying O/S epoch (which usually means UTC). I didn't mean that Perl is using a TAI library, but the TAI time system or TAI calendar. The reason why I suggested TAI was that in the TAI time system there are no leap seconds and every second has the same length. GMT doesn't have leap seconds either, but the length of each second is not a fixed value. 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 Jun 30 23:59:59 1972 Fri Jun 30 23:59:60 1972 Sat Jul 1 00:00:00 1972 The second before 1972-07-01 00:00:00 UTC was a leap second (the first leap second after 1970). Every version of Perl I have available gives me $ perl -wle 'print scalar gmtime $_ for 78796799 .. 78796801' Fri Jun 30 23:59:59 1972 Sat Jul 1 00:00:00 1972 Sat Jul 1 00:00:01 1972 happily ignoring the leap second. Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
RE: ISO 8601 is eeeevil!
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 pain in the butt. Those who wrote the standard could, of course, have disallowed all formats which are ambiguous, but these formats are sometimes useful, so they allowed them on the condition that everone agrees on what the ambiguous formats are supposed to mean. I have to say that I agree with Peter here. A standard set of library modules cannot, by definition, support whatever outside agreements might be in place between two organizations. Any module that purports to be generally useful should simply disallow ambiguity by never assuming that a format is an expanded (per the ISO definition) one. Jerry I concur. An interesting challenge here might be to devise a way to allow DateTime to exploit the full range of ISO 8601 formats, in cases where the user knows that the appropriate agreements exist among the parties. Perhaps a DT::F::ISO8601 parameter like accept = ['DDD'], could be used, evoking the necessary routines to parse format. (I put this in the form of an array ref to handle multiple accepts.) Just a thought. - Bruce
Re: Getting different results from DateTime and Manip for epoch time
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 time. Since 1986 at
least, anyone referring to GMT was actually talking about UTC, i.e. EST is UTC-4
_not_ GMT-4. GMT was always a social convention, and as such, people still use
it in the colloquial sense. UTC is an international standard, based on precise
rules and measurements, which is nonetheless employed in exactly the same
situations as formerly covered by GMT.
I have no argument that the definition of UTC is completely different from the
loosely defined GMT. However, it is clear that GMT lead directly to UTC (which
is why the Zulu timezone is still Greenwich. And it is also clear that when
most people today refer to GMT, they are actually talking about UTC. Only us
time weenies (and astronomers) care about the details...
Perl is not using TAI, but rather the underlying O/S epoch
(which usually means UTC).
I didn't mean that Perl is using a TAI library, but the TAI time
system or TAI calendar. The reason why I suggested TAI was that
in the TAI time system there are no leap seconds and every second
has the same length. GMT doesn't have leap seconds either, but
the length of each second is not a fixed value.
Perl is _not_ using TAI, since it is employing an epoch corresponding to the
Unix epoch (except on Mac's???). It is, however, not correctly handling
leapseconds, which isn't too suprising since hardly anything does. NTP, for
example, does not handle leapseconds either.
See this discussion by Dr. Bernstein:
http://cr.yp.to/proto/utctai.html
In it, he suggests that some O/S vendors have correctly patched localtime() to
use the Olson library (in strict violation of POSIX specs). At least on the
*nix's I have here, I see no sign of leap seconds:
$ cat test.c
#include stdio.h
#include time.h
int main(void)
{
time_t result;
for ( result = 78796799; result =78796801; result++)
{
printf(%s, asctime(gmtime(result)));
}
return(0);
}
yields
$ ./test
Fri Jun 30 23:59:59 1972
Sat Jul 1 00:00:00 1972
Sat Jul 1 00:00:01 1972
which is the same output as Perl.
John
--
John Peacock
Director of Information Research and Technology
Rowman Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
Re: Getting different results from DateTime and Manip for epoch time
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 Jun 30 23:59:59 1972
Fri Jun 30 23:59:60 1972
Sat Jul 1 00:00:00 1972
This is a correct implementation of UTC time; and as you say, this is
rarely implemented.
The second before 1972-07-01 00:00:00 UTC was a leap second (the
first leap second after 1970). Every version of Perl I have
available gives me
$ perl -wle 'print scalar gmtime $_ for 78796799 .. 78796801'
Fri Jun 30 23:59:59 1972
Sat Jul 1 00:00:00 1972
Sat Jul 1 00:00:01 1972
happily ignoring the leap second.
This looks like TAI, but it isn't. Perl uses UTC, but skips the leap
seconds. You can see this in local times. For example, MET is defined
as UTC+0100, not as TAI+0100. In perl:
$ perl -wle 'print scalar localtime $_ for 78796799 .. 78796801'
Sat Jul 1 00:59:59 1972
Sat Jul 1 01:00:00 1972
Sat Jul 1 01:00:01 1972
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 1972
(because UTC=TAI-10s, TAI and MET differed 1 hour and 10 seconds in
1972)
And if Perl used real UTC, the output would have been
$ perl -wle 'print scalar localtime $_ for 78796799 .. 78796801'
Sat Jul 1 00:59:59 1972
Sat Jul 1 00:59:60 1972
Sat Jul 1 01:00:00 1972
If you want to have a libtai-like epoch, which counts the leap seconds,
use the DateTime::Format::Epoch module:
use DateTime::Format::Epoch;
my $dt = DateTime-new( year = 1970, month = 1, day = 1 );
my $tai = DateTime::Format::Epoch-new(epoch=$dt, skip_leap_seconds=0);
my $utc = DateTime::Format::Epoch-new(epoch=$dt, skip_leap_seconds=1);
for (78796799 .. 78796803) {
print DateTime-from_epoch(epoch = $_)-datetime,,
$tai-parse_datetime($_)-datetime,,
$utc-parse_datetime($_)-datetime, \n;
}
1972-06-30T23:59:59 1972-06-30T23:59:58 1972-06-30T23:59:59
1972-07-01T00:00:00 1972-06-30T23:59:59 1972-07-01T00:00:00
1972-07-01T00:00:01 1972-06-30T23:59:60 1972-07-01T00:00:01
1972-07-01T00:00:02 1972-07-01T00:00:00 1972-07-01T00:00:02
1972-07-01T00:00:03 1972-07-01T00:00:01 1972-07-01T00:00:03
DateTime objects are of course in UTC. Perhaps a DateTime::Format::TAI
is needed?
Eugene
P.S. It looks like there was a leap second before 1972-06-30. Is that
correct?
Re: All you astro people (and math freaks)
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 decrease towards noon and then increase again towards midnight. I figured this is a sine wave. That would perhaps be nicer for us computer-owning people, but that wasn't how it was implemented in ancient times. It is really much easier to have only two different hour lengths per day. You only need two different clepsydras that way. And many people only used the day-hours; there were few public events in the evening or night: no electric lights. So nights were spent mostly at home, where the time of day was not important. 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. Eugene
Re: ISO 8601 is eeeevil!
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 not be settled yet, I will try to get the module out so people can better see what I have in mind and critique working code. -ben On Thu, Jun 19, 2003 at 11:35:58AM -0700, Bruce Van Allen wrote: An interesting challenge here might be to devise a way to allow DateTime to exploit the full range of ISO 8601 formats, in cases where the user knows that the appropriate agreements exist among the parties. Perhaps a DT::F::ISO8601 parameter like accept = ['DDD'], could be used, evoking the necessary routines to parse format. (I put this in the form of an array ref to handle multiple accepts.) Just a thought. - Bruce
Re: Having problems with Datetime-format-Strptime-1.02 install on Wi n32
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 --
Re: Jalali Calendar
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 Calculations it says the Jalali calendar used 30 day months while the Persian calendar used 29,30, and 31 day months. -J --
Re: Getting different results from DateTime and Manip for epoch time
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 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. It is, however, not correctly handling leapseconds, which isn't too suprising since hardly anything does. NTP, for example, does not handle leapseconds either. I'm not surprised either that leapseconds are rarely implemented, since time arithmetic is much easier if you drop the leap seconds. But software not handling leap seconds is not using the UTC time system. Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
Re: Getting different results from DateTime and Manip for epoch time
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 1972 (because UTC=TAI-10s, TAI and MET differed 1 hour and 10 seconds in 1972) Ah. Good grief. You're absolutely right. 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 Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
Re: ISO 8601 is eeeevil!
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) # month -? # possible hyphen (\d\d) # day (?:T # time is optional (\d\d) # hours :(\d\d)# minutes (?:# seconds are optional :(\d\d) # seconds )? )? /x 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 (-?) # possible hyphen (\d\d) # month \2 # possible hyphen (\d\d) # day ... ... Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
Re: Getting different results from DateTime and Manip for epoch time
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 start with 0 at Jan 1, 1970 (Unix epoch), but with the hex value 4000 for that instant in time. Perl5 uses the Unix epoch as the basis for it's time (for historical reasons). Perl6 may use TAI. That's TAI64, an epoch count based on the time scale TAI. TAI 64 starts at Jan 1, 1970 (TAI) = Dec 31, 1969 23:59:xx UTC. If TAI is defined to start somewhere, it's at 01-01-01 00:00:00 TAI, or possibly 01-01-00 00:00:00 TAI, as it's an astronomical scale. TAI64 is to TAI as the Unix epoch is to UTC. By the way, the next version of DateTime::Format::Epoch will contain a TAI64 implementation. It will be on CPAN later today. Eugene
Re: Jalali Calendar
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
Re: ISO 8601 is eeeevil!
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 was thinking about DateTime::Format::ISO8601... unless you have laid claim to it. I don't know if I will manage to finish this thing, it is a bit of a monster. -ben
Slides from YAPC presentation
I put these on datetime.perl.org. They're linked from the resources page. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
catching up
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.houseabsolute.com ===*/
Re: ISO 8601 is eeeevil!
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 --
DT::F::Epoch
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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
