Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[GregLondon]

J. David Blackstone wrote:

>  I always treat the return value of time() as a black-box value.  I
>can perform specific actions on it, such as feeding it to localtime()
>or adding relative time intervals to it, such as a year of seconds.
>But I do not allow myself to look at that value.  I was kind of hoping
>Perl6 would formalize this into a black-box value, meaning an object,
>and offload everything into a standard module instead of the core.

thinking about it, I like that idea the best.
for a script to really be cross-platform independent (i.e. a "good" script)
then it can't make assumptions about the internal representation of time.
And if its hidden, then you can change epochs, change operating systems,
and change religions, and your script really wont care.

you'd have three basic things you could do:

1) get calendar time, which would return a year, month, day, hour, minute,
second.
defaulting to the gregorian calendar

2) start stopwatch: which sets a stopwatch to zero, and then you can poll
it
to see how much time has elapsed since you started the stop watch.
default units would be seconds

3)perform some arithemetic on these two things.
 calendar - calendar = elapsed time
 calendar + elapsed time = new calendar time
 etc, etc

both of these could be objects and would enforce the black box.
calendar time would be a static object representing a fixed point in time.
stopwatch would be a dynamic object with a reset and polling method
 to return time elapsed since last reset.

calendar time would have a method that spits out  a string formatted
to the proper, non-ambigous representation,
("16 August, 2000, 11:56 A.M." )
then when 2099 rolls around,  there shouldn't be any Y2.1K problem...

;)

Greg London
always planning ahead

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Jeremy Howard]

> On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote:
> > [EMAIL PROTECTED] writes:
> > : Yep.  Or more generally "Standardize Perl on all platforms to one
> > : common time epoch" and reccommend the Unix epoch since it's so
> > : widespread.  :-)
> >
> > Oh, gee, where's your sense of history?  (As in creating our own. :-)
> > Maybe we should invent our own epoch, like the year 2000.  Or use a
> > really standard one, like the year 0 AD (aka 1 BC).
> >
> > I have this horror that people will still be using 1970 as the epoch in
> > the year 31,536.
>
Actually, Damian Conway came up with a good one last night. His suggestion
was that the time at which we decide what to use as the start of our epoch,
should be the time that we use as the start of our epoch. Now that's
creating our own history!

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Tim Bunce]

On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> : Yep.  Or more generally "Standardize Perl on all platforms to one
> : common time epoch" and reccommend the Unix epoch since it's so
> : widespread.  :-)
> 
> Oh, gee, where's your sense of history?  (As in creating our own. :-)
> Maybe we should invent our own epoch, like the year 2000.  Or use a
> really standard one, like the year 0 AD (aka 1 BC).
> 
> I have this horror that people will still be using 1970 as the epoch in
> the year 31,536.

I tend to thing this whole epoc thing is overblown.

Few people would know what this time was just by looking at it: 966421517

So what does it matter if that time was represented by another string
of digits?  What difference does it _really_ make what epoc is used, so
long as it's fully integrated into the language and interfaces along
with appropriate conversions to other epocs?

I tend to think that perl time should not break when presented with
Larry's date of birth :-)

We also need to avoid the unixtime 2038 bug, one way or another..

Tim.

p.s. For reference, Oracle DATE type can handle all dates from January 1,
4712 BC to December 31, 4712 AD. Oracle also supports a very wide range
of date formats and can use one of several calendars (Arabic Hijrah,
English Hijrah, Gregorian, Japanese Imperial, Persian, ROC Official
(Republic of China) and Thai Buddha).

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Bryan C . Warnock]

On Tue, 15 Aug 2000, Nathan Wiger wrote:
> Jarkko Hietaniemi wrote:
> > 
> > > Is Perl currently using different epochs on different platforms?  If so, I
> > 
> > Yes.  MacOS and VMS.  (Though VMS' localtime() uses the UNIX definition,
> > just to be portable.)  MacOS' epoch zero is 1900 (or was it 1901?),
> > VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
> > reason IIRC.
> 
> This is the real point I'm trying to address. Nothing else. :-)
> 
> There seems to be a groundswell against this idea, which is fine by me
> (heck, just because it's my idea doesn't me it's a GOOD one!).
> 
> Here's a different proposal, same vein: "Standardize all Perl platforms
> on the UNIX epoch".
> 
> Sound better?

Only if all the OSes are rewritten to use the standard UNIX epoch as
well.

Internally, you should use whatever the platform you're running on uses.
Externally, you can use whatever you'd like.

> 
> -Nate
-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[J. David Blackstone]

>> Is Perl currently using different epochs on different platforms?  If so, I
>
> Yes.  MacOS and VMS.  (Though VMS' localtime() uses the UNIX definition,
> just to be portable.)  MacOS' epoch zero is 1900 (or was it 1901?),
> VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
> reason IIRC.

  perlfunc states that time() returns seconds since machine epoch,
noting that it varies from platform to platform.  (As some have noted,
the Mac epoch is in 1904.  I think this is so you can divide the years
since epoch by 4 and have the remainder indicate the leap-year
condition.  Wouldn't have worked for 1900, and most of us have
probably dealt with that fact at some point, by now.)

  It might be advisable for portability concerns to standardize on an
epoch.  If so, this Mac user would vote for the UNIX epoch.  It is
simply the most widely accepted.  I'm not sure what Windows does, but
I thought I might have seen something that implied it was using (or at
least converting to and from) UNIX epoch.  Mac will probably use that
epoch, anyway, once OS X comes out (which will fuse Mac OS and UNIX in
what I expect will be a beautiful way).

  I always treat the return value of time() as a black-box value.  I
can perform specific actions on it, such as feeding it to localtime()
or adding relative time intervals to it, such as a year of seconds.
But I do not allow myself to look at that value.  I was kind of hoping
Perl6 would formalize this into a black-box value, meaning an object,
and offload everything into a standard module instead of the core.


  Kirrily and Dan, isn't it time for a time and date sublist?

J. David

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[J. David Blackstone]

> On 14 Aug 2000, Russ Allbery wrote:
> 
>> Day resolution is insufficient for most purposes in all the Perl scripts
>> I've worked on.  I practically never need sub-second precision; I almost
>> always need precision better than one day.
>>
>
> MJD allows fractional days (otherwise it would of course be useless).
>
> As I write this the MJD is 51771.20833

  I recognize that a lot of software packages out there are using MJD,
but I don't really feel that fractions of days, hours, or minutes are
intuitive.  Mankind has had sixty seconds in a minute, sixty minutes
in an hour, twelve hours in a day, and so on up, for centuries.
Arguably, better systems could be created, and perhaps MJD is such a
system, but it is very hard to change the instincts and habits built
on older systems.  (Just look at how slowly the U.S. is moving to
metric.)

  I would really rather not see this change, or see the number
expressed in seconds.  (MJD as seconds would really amount to just
moving the epoch, and I don't think that would make anyone happy.)

  I still lean towards thinking that anything involving a date should
be pushed out into a module.  There could be a date module (or two)
included as standard, and people who want MJD or other systems, or
fractions of a second, or whatever, could totally ignore the standard
module and use a different one.

J. David

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Glenn Linderman]

There is already precedent (-M, et alia) for a "perl epoch" which is time
since the start of execution of the script.  Negative numbers are used to
represent times prior to the start of execution, and positive numbers are used
to represent times after the start of execution.

The "perl epoch" doesn't suffer from Y2K syndrome :)   (irrelevant comment)

In perl 5, the perl epoch is definitely based on days since the time() $^T the
script started.

Really, once you define a mechanism for storing a sufficiently large time of
adequate span and resolution (64 bits?), the remaining problem is just a
matter of selecting a base time (what does 0 mean?), and the units (what does
1 mean?).  Given a base time and the units...

...conversions between MJD and the perl epoch, between UTC and the perl epoch,
and between common current time in any time zone and the perl epoch, should
just be a single subtract each, so a few constants (and a time zone offset
setting) in a module should be able to give anyone interested in any of those
the actual time.

...conversions between at least one of the above, and Gregorian dates should
be available.

...the time objects provided by perl should allow users to:

  : obtain nicely formatted times in any of the above systems
  : supply a timezone offset, and obtain nicely formatted dates in any
timezone
  : obtain any/all of the numeric component parts of any of the above times.

Such will take quite a few methods on a class, or a function returning a large
number of components or keys & values.

For consistency, it would be nice if all the perl APIs used the same epoch
when dealing in binary timestamp values and that conversions from host
operating system API formats would happen automatically.

Russ correctly points out that Unix's time representation format has no
fundamental problems that can't be solved by simple workarounds.  Neither does
MJD or UTC.  There is no universal epoch among platforms or operating
systems.  Picking Unix time would make one user community happy, picking
Windows time would make a different user community happy, picking MJD would
make a different user community happy, there is no epoch that would make
everyone happy, so I propose the perl epoch be based on the time the script
starts running, similar to -M, but perhaps with a different unit than days
(which implies floating point) if we want a 64 bit integer representation.

Keeping the base consistent with other applications is only relevant if
reading and writing binary form timestamps created by the other
applications conversion to/from the binary form used by those other
applications should be encapsulated on two functions that read/write the
binary data from those other applications.  For a Unix user that is likely to
require a different conversion that a Windows user.  Converting to/from Unix
binary timestamps and Windows binary timestamps would be nice convenience
functions to have built in to perl.  I would even find the conversion to/from
Unix timestamps handy on Windows, and vice versa, for data that is networked.

Russ Allbery wrote:

> Unix's time representation format has no fundamental problems that aren't
> simple implementation issues.  Negative values represent times before 1970
> just fine.  The range problem is easily solved by making it a 64-bit
> value, something that apparently we'd need to do with an MJD-based time
> anyway.  And everyone already knows how it works and often relies on the
> base being consistent with their other applications.

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



_NetZero Free Internet Access and Email__
   http://www.netzero.net/download/index.html

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Gisle Aas]

[EMAIL PROTECTED] writes:

> Midnight, Jan 1, 2000, Greenwich time
> 
> seems like a good candidate.

 have found 2000-03-01 to be a
good epoch.  It makes -mm-dd decoding and leap year calculations
cheaper/simpler as it is the closest start of a new 400 year leap-year
cycle.

Regards,
Gisle

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Dan Sugalski]

At 02:23 PM 8/15/00 -0400, [EMAIL PROTECTED] wrote:
>Modified Julian Day 0 thus started on 17 Nov 1858 (Gregorian) at 00:00:00
>UTC.
>(somebody threw that date out, It appears to be purely
>arbitrary rather than based on some celestial event)

Not arbitrary at all. From: http://www.kgb.com/calend.html

This information comes from the original (pre-Motif) DECwindows help file
which accompanied VMS version 5.3.
by Marios Cleovoulou
http://ourworld.compuserve.com/homepages/cleovoulou/
Copyright © 1988, 1989 by Digital Equipment Corporation.

>The Julian Period
>
>Astronomers use the Julian period because it is convenient to express
>long time intervals in days rather than months, weeks and years. It
>was devised by Joseph Scaliger, in 1582, who named it after his father
>Julius, thus creating the confusion between the Julian (Caesar)
>calendar and the Julian (Scaliger) period.
>
>Julian Day 1 began at 12:00 noon, January 1, 4713 BC. This date was
>thought by some to correspond approximately to the beginning of the
>universe. Certainly it predated any known astronomical events known in
>the 16th century without resorting to negative times. Scaliger decided
>on the actual date on the grounds that it was the most recent
>coincidence of three major chronological cycles:
>
>- The 28-year solar cycle, after which dates in the Julian calendar
>(for example September 27) return to the same days of the week (for
>example Tuesday).
>
>- The 19-year lunar cycle, after which phases of the moon return to
>the same dates of the year.
>
>- The 15-year indiction cycle, used in ancient Rome for tax regulation.
>
>It takes 7980 years to complete the cycle. Noon of January 1, 1988,
>marks the beginning of Julian Day 2447161.
>
>The Julian period is also of interest because of its use as a time
>base by the VMS operating system.
>
>VMS and the Julian Period or:
>Why VMS regards November 17, 1858, as the beginning of time...
>
>The modified Julian date adopted by SAO (Smithsonian Astrophysical
>Observatory) for satellite tracking is Julian Day 240, which turns
>out to be November 17, 1858.
>
>SAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704
>in 1957, when Sputnik went into orbit. The Julian day was 2435839 on
>January 1, 1957. This is 11225377 octal, which was too big to fit into
>an 18-bit field. With only 8K of memory, the 14 bits left over by
>keeping the Julian date in its own 36-bit word would have been
>wasted. They also needed the fraction of the current day (for which 18
>bits gave enough accuracy), so it was decided to keep the number of
>days in the left 18 bits and the fraction of a day in the right 18
>bits of one word.
>
>Eighteen bits allows the truncated Julian day (the SAO day) to grow as
>large as 262143, which from November 17, 1858, allowed for 7
>centuries. Possibly, the date could only grow as large as 131071
>(using 17 bits), but this still covers 3 centuries and leaves the
>possibility of representing negative time. The 1858 date preceded the
>oldest star catalogue in use at SAO, which also avoided having to use
>negative time in any of the satellite tracking calculations.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[GregLondon]

Jonathan wrote:
>
>On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote:
>> I don't know about this. Sounds cool, but I think we should stick to
>> something that somebody somewhere uses already. Of course, something
>> standard like 0 AD isn't bad.
>
>Standard for whom?  I bet there are *millions* of Jews for whom "0 AD"
>is meaningless.  s/Jews/calendar that predates christianity>/

excerpts from :

  http://webexhibits.org/calendars/index.html

the Islamic calendar is based on the motion of the moon,
while the year has no connection with the motion of the earth around the
sun.

But even worse, you can't just do some math and convert a
number of seconds into a old, old date, because the old calendars
were so messed up.

Before Julius Caesar introduced the Julian calendar in 45 B.C.E.,
the Roman calendar was a mess, and much of our so-called
"knowledge" about it seems to be little more than guesswork.

Originally, the year started on 1 March and consisted of only 304
days or 10 months  These 304 days were followed by an unnamed
and unnumbered winter period.

In practice it was the duty of the priesthood to keep track of the
calendars,
but they failed miserably, partly due to ignorance, partly because they
were bribed to make certain years long and other years short.
Furthermore, leap years were considered unlucky and were therefore
avoided in time of crisis, such as the Second Punic War.

The Julian calendar was introduced by Julius Caesar in 45 B.C.E.
It was in common use until  the 1500s, when countries started changing
to the Gregorian calendar. However, some countries (for example,
Greece and Russia) used it into this century, and the Orthodox church in
Russia still uses it, as do some other Orthodox churches.

Modified Julian Day 0 thus started on 17 Nov 1858 (Gregorian) at 00:00:00
UTC.
(somebody threw that date out, It appears to be purely
arbitrary rather than based on some celestial event)

The calendar used throughout the world today is the Gregorian calendar.
It was proposed by Aloysius Lilius, a physician from Naples, and adopted
by Pope Gregory XIII  in accordance with instructions from the Council of
Trent
(1545-1563) to correct for errors in the older Julian Calendar.

By 1582 vernal equinox had moved (1582-325)/128 days = approximately 10
days backwards (because of the Julian calendar errors)
So 10 days had to be dropped.

In the Gregorian calendar, the tropical year is approximated as
365 97/400 days = 365.2425 days. Thus it takes approximately 3300 years
for the tropical year to shift one day with respect to the Gregorian
calendar.

The approximation 365 97/400 is achieved by having 97 leap years every 400
years.

a year's length is currently  365.242190 days,  but it varies.
Around 1900 its length was 365.242196 days,
and around  2100 it will be   365.242184 days.

<<< end of excerpt >>>

the further back you go in history, the less accurate your
 dates will be (if you want to convert a modern calendar date
 to a Roman calendar date, you'll have a TON of if-then-else's
 to handle) and even then, some of it is guess work.

this seems to rule out the idea of using 0 AD as a reference date.


All calendar systems are arbitrary. there is nothing that says
 solar days are a better measure than lunar months
 (for a given definition of "better")
 they are both celestial events, and neither one of them
 has a fixed, constant, period or rate.

you could argue that one is religiously biased, or you
could simply say that most of the people developing perl
use the gregorian calendar, and the developers get to pick.

by the same token, you could say that Greenwich England
is a lousy place to define the Universal Time Zone,
(the weather is miserable, the food is terrible, and the people are rude)
 but, hey, almost everyone draws the zeroeth longitude through
that city. so most time calculations are based off of the time there.
but they happen to be the first to make navigational charts
and they had to put zero somewhere.

then the term "second" is arbitrary as well.
12 hours in the day and 12 hours in the night
(because their happen to be 12 months in the year?)
60 minutes in an hour and 60 seconds in a minute.
(there are 360 degrees in a circle because there
are about 365 days in a year, and 360 divided
very very nicely. and again, it worked out that
navigation using sextants wanted to keep things
as simple as possible, so easily dividible numbers
were quite desirable.)

so its all arbitrary.

but most people developing perl use the gregorian
calendar. and it seems to be fairly widespread
as far as calendars go. and in the spirit of
"the first ones there get to define the rules",
it would seem appropriate that teh perl epoch
be based off of some event on the gregorian
calendar.  given the problems with earlier calendar
systems, it should be a recent (in the relative sense
of the word recent) event.

Midnight, Jan 1, 2000, Greenwich time

seems like a good candid

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  Dan Sugalski <[EMAIL PROTECTED]> wrote:

> I think I'd snag a date after the last western country went Julian, just to
> avoid some of the less fun time conversion issues. (How long ago Jan 1,
> 1690 was depends on what country you're in)

I think you mean Gregorian, not Julian. If that's going to be your
requirement then you need to pick a date in the 20th century I think
as IIRC Russia didn't go Gregorian until then...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...I haven't had sex in so long, I forget who gets tied up!

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Nathan Wiger]

Jonathan Scott Duff wrote:
>
>> standard like 0 AD isn't bad.
>
> Standard for whom?  I bet there are *millions* of Jews for whom "0 AD"
> is meaningless.  s/Jews/ calendar that predates christianity>/

Good point.

Unix epoch it is! :-)

-Nate

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Dan Sugalski]

At 09:25 AM 8/15/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: Yep.  Or more generally "Standardize Perl on all platforms to one
>: common time epoch" and reccommend the Unix epoch since it's so
>: widespread.  :-)
>
>Oh, gee, where's your sense of history?  (As in creating our own. :-)
>Maybe we should invent our own epoch, like the year 2000.  Or use a
>really standard one, like the year 0 AD (aka 1 BC).

I think I'd snag a date after the last western country went Julian, just to 
avoid some of the less fun time conversion issues. (How long ago Jan 1, 
1690 was depends on what country you're in)

While I personally like the smithsonian base date (17-nov-1858) that's 
rather parochial (well, US-centric) and difficult to remember. If we're 
picking a new one, I'm partial to Jan 1, 2000. Or shall we choose year 0 in 
the Chinese calendar?

>I have this horror that people will still be using 1970 as the epoch in
>the year 31,536.

Nah. I'm sure we'll have switched over to Elvis' birthday as base date by 
then... :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Jonathan Scott Duff]

On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote:
> I don't know about this. Sounds cool, but I think we should stick to
> something that somebody somewhere uses already. Of course, something
> standard like 0 AD isn't bad.

Standard for whom?  I bet there are *millions* of Jews for whom "0 AD"
is meaningless.  s/Jews//

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Jonathan Scott Duff]

On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> : Yep.  Or more generally "Standardize Perl on all platforms to one
> : common time epoch" and reccommend the Unix epoch since it's so
> : widespread.  :-)
> 
> Oh, gee, where's your sense of history?  (As in creating our own. :-)
> Maybe we should invent our own epoch, like the year 2000.  Or use a
> really standard one, like the year 0 AD (aka 1 BC).

Well, if I had my history sense, I'd've recommended that we start our
epoch at about 4.5 billion years ago to keep the geologists happy and
if those cosmologists had their act together maybe I'd've recommended
we start our epoch at about 15 billion years ago.  ;-)

> I have this horror that people will still be using 1970 as the epoch in
> the year 31,536.

You can almost count on it.  But that won't be our fault as much as
Unix's :-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Nathan Wiger]

Larry Wall wrote:
> 
> Oh, gee, where's your sense of history?  (As in creating our own. :-)
> Maybe we should invent our own epoch, like the year 2000.  Or use a
> really standard one, like the year 0 AD (aka 1 BC).

I don't know about this. Sounds cool, but I think we should stick to
something that somebody somewhere uses already. Of course, something
standard like 0 AD isn't bad.

> I have this horror that people will still be using 1970 as the epoch in
> the year 31,536.

Yeah, but by then we'll be on Perl 203.4.2 and it'll be our children's
children's children's children's issue (assuming Perl and computers are
still around even).

Plus, at least the difference between the UNIX epoch and 31,536 is 1970
less than the difference between 0 AD and 31,536. (For those counting
bits.) :-)

-Nate

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Larry Wall]

[EMAIL PROTECTED] writes:
: Yep.  Or more generally "Standardize Perl on all platforms to one
: common time epoch" and reccommend the Unix epoch since it's so
: widespread.  :-)

Oh, gee, where's your sense of history?  (As in creating our own. :-)
Maybe we should invent our own epoch, like the year 2000.  Or use a
really standard one, like the year 0 AD (aka 1 BC).

I have this horror that people will still be using 1970 as the epoch in
the year 31,536.

Larry

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Jonathan Scott Duff]

On Tue, Aug 15, 2000 at 08:44:48AM -0700, Nathan Wiger wrote:
> There seems to be a groundswell against this idea, which is fine by me
> (heck, just because it's my idea doesn't me it's a GOOD one!).
> 
> Here's a different proposal, same vein: "Standardize all Perl platforms
> on the UNIX epoch".
> 
> Sound better?

Yep.  Or more generally "Standardize Perl on all platforms to one
common time epoch" and reccommend the Unix epoch since it's so
widespread.  :-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Nathan Wiger]

Jarkko Hietaniemi wrote:
> 
> > Is Perl currently using different epochs on different platforms?  If so, I
> 
> Yes.  MacOS and VMS.  (Though VMS' localtime() uses the UNIX definition,
> just to be portable.)  MacOS' epoch zero is 1900 (or was it 1901?),
> VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
> reason IIRC.

This is the real point I'm trying to address. Nothing else. :-)

There seems to be a groundswell against this idea, which is fine by me
(heck, just because it's my idea doesn't me it's a GOOD one!).

Here's a different proposal, same vein: "Standardize all Perl platforms
on the UNIX epoch".

Sound better?

-Nate

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Jonathan Scott Duff]

On Mon, Aug 14, 2000 at 08:40:32PM -0700, Nathan Wiger wrote:
> No, but currently Perl IS forcing Windows, Mac, and BeOS users to
> understand what the UNIX epoch is. 

So you're proposing that rather than give one platform (unix) an
advantage, we force all platforms to use some other completely
arbitrary date/time format?

> There's some other advantages to MJD beyond system-independence. Namely,
> it allows easy date arithmetic, meaning complex objects are not required
> to modify dates even down to the nanosecond level.

Sorry, but date arithmetic is easy now:

$then = time();
# time passes
$now = time();
$difference = $now - $then; # How long was that?

And as to modifying dates "down to the nanosecond", you're proposing
that these MJD dates be floating point numbers.  Why not ust make
time() return a float and *bam* you've got <1 second precision as far
as your floats or doubles can carry you.

> But make the core language easily accessible to everyone.

Funny, that's the exact argument I would use *against* mjdate().

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Dan Sugalski]

At 10:56 PM 8/14/00 -0500, Jarkko Hietaniemi wrote:
> > Is Perl currently using different epochs on different platforms?  If so, I
>
>Yes.  MacOS and VMS.  (Though VMS' localtime() uses the UNIX definition,
>just to be portable.)  MacOS' epoch zero is 1900 (or was it 1901?),
>VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
>reason IIRC.

It's the Smithsonian Base Date, FWIW. On VMS, though, perl presents all 
time in Unix epoch seconds.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Chaim Frenkel]

> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:

RA> Is Perl currently using different epochs on different platforms?  If so, I
RA> can definitely see the wisdom in doing something about *that* and
RA> off-loading the system-local time processing into modules (although I can
RA> also see the wisdom in leaving well enough alone).  But why not go with
RA> the most commonly used and most widely analyzed epoch?

Folks, the only problem that everyone seems to be arguing about is
what the EPOCH is. Who cares what the epoch is?

Create $Perl::Time{EPOCH} and be done with it.

As long as I can add and subtract a reasonable range of time values and
get a reasonable result I'm happy.

There should be no assumption that 0 is the epoch. It might well be
that some other arbitrary number is the limit of valid time. So unless
perl is going to distribute portable time and date calcuations, as
part of the core, we will have to live with whatever the system
libraries give us.

(I don't want to think about Leap Seconds just yet.)


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Russ Allbery]

Tim Jenness <[EMAIL PROTECTED]> writes:
> On 14 Aug 2000, Russ Allbery wrote:

>> Day resolution is insufficient for most purposes in all the Perl
>> scripts I've worked on.  I practically never need sub-second precision;
>> I almost always need precision better than one day.

> MJD allows fractional days (otherwise it would of course be useless).

> As I write this the MJD is 51771.20833

Floating point?  Or is the proposal to use fixed-point adjusted by some
constant multiplier?  (Floating point is a bad idea, IMO; it has some
nasty arithmetic properties, the main one being that the concept of
incrementing by some small amout is somewhat ill-defined.)

> At some level time() will have to be changed to support fractions of a
> second and this may break current code that uses time() explicitly
> rather than passing it straight to localtime() and gmtime().

Agreed.

I guess I don't really care what we use for an epoch for our sub-second
interface; I just don't see MJD as obviously better or more portable.  I'd
actually be tentatively in favor taking *all* of the time stuff and
removing it from the core, under the modularity principal, but I don't
have a firm enough grasp of where the internals use time to be sure that's
a wise idea.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Tim Jenness]

On 14 Aug 2000, Russ Allbery wrote:

> Day resolution is insufficient for most purposes in all the Perl scripts
> I've worked on.  I practically never need sub-second precision; I almost
> always need precision better than one day.
> 

MJD allows fractional days (otherwise it would of course be useless).

As I write this the MJD is 51771.20833

> If we're aiming at replacing time, it has to provide *at least* second
> precision, at which point I really don't see the advantage of MJD over
> Unix time.  Why change something that works?

It should be able to provide this precision and more.

At some level time() will have to be changed to support fractions of a
second and this may break current code that uses time() explicitly
rather than passing it straight to localtime() and gmtime().

As long as I can do simplistic date arithmetic with the return value
of time() and retrieve that from the equivalent date() object I will be
happy.

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Damian Conway]

   > Yes.  MacOS and VMS.  (Though VMS' localtime() uses the UNIX definition,
   > just to be portable.)  MacOS' epoch zero is 1900 (or was it 1901?),

1904 (if it matters).

Damian

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Jarkko Hietaniemi]

> Is Perl currently using different epochs on different platforms?  If so, I

Yes.  MacOS and VMS.  (Though VMS' localtime() uses the UNIX definition,
just to be portable.)  MacOS' epoch zero is 1900 (or was it 1901?),
VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
reason IIRC.

> can definitely see the wisdom in doing something about *that* and
> off-loading the system-local time processing into modules (although I can
> also see the wisdom in leaving well enough alone).  But why not go with
> the most commonly used and most widely analyzed epoch?

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Russ Allbery]

Nathan Wiger <[EMAIL PROTECTED]> writes:

>> Anyway, it doesn't matter; it's a lot more widely used than any other
>> epoch, and epochs are completely arbitrary anyway.  What's wrong with
>> it?

> I think the "What's wrong with it?" part is the wrong approach to this
> discussion.

That's exactly what I disagree with, I think.  I don't understand why this
would be the wrong approach to the discussion.  It seems to me that it
follows automatically from "epochs are completely arbitrary anyway."

> That being said, what we need to say "is it possible UNIX might not be
> perfect?" (hard to imagine, true... :-). More specifically, "is there
> something that would work better for putting Perl in Palm pilots,
> watches, cellphones, Windows and Mac hosts, *plus* everything else it's
> already in?"

How does it make any difference what epoch you use?  Why would this make
Perl more portable?

> No, but currently Perl IS forcing Windows, Mac, and BeOS users to
> understand what the UNIX epoch is.

In that case, I don't understand what the difference is between that and
forcing those users *plus* Unix users to understand what the MJD epoch is.

> There's some other advantages to MJD beyond system-independence.

But MJD isn't any more system-independent than Unix time.  Absolutely
nothing about Unix time is specific to Unix; it's just as portable as any
other arbitrary epoch.

> Namely, it allows easy date arithmetic, meaning complex objects are not
> required to modify dates even down to the nanosecond level.

Unix time allows this down to the second level already.  If we wanted to
allow it down to the nanosecond level through a different interface to
return something like TAI64NA or something, that would make sense to me.
What doesn't make sense to me is a change of epoch; I just don't see what
would be gained.

I must be very confused.  I don't understand what we gain from MJD dates
at all, and the arguments in favor don't make any sense to me; all of the
advantages listed apply equally well to the time system we have already.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Nathan Wiger]

> Anyway, it doesn't matter; it's a lot more widely used than any other
> epoch, and epochs are completely arbitrary anyway.  What's wrong with it?

I think the "What's wrong with it?" part is the wrong approach to this
discussion. Personally, I'm a 100% UNIX head. All I work on is UNIX
(thank heavens). And that's all I even plan on using; after all, I'm a
UNIX sysadmin. So, time() actually makes more sense to me than mjdate(),
even though I proposed the RFC.

That being said, what we need to say "is it possible UNIX might not be
perfect?" (hard to imagine, true... :-). More specifically, "is there
something that would work better for putting Perl in Palm pilots,
watches, cellphones, Windows and Mac hosts, *plus* everything else it's
already in?"

> Is Perl currently using different epochs on different platforms? 

No, but currently Perl IS forcing Windows, Mac, and BeOS users to
understand what the UNIX epoch is. 

There's some other advantages to MJD beyond system-independence. Namely,
it allows easy date arithmetic, meaning complex objects are not required
to modify dates even down to the nanosecond level.

One thing C has done well that we can learn from is making libraries
system-dependent, but the language system-independent. Leave time() and
localtime() (UNIX dependent) in Unix::Time or some other module, easily
accessible through a "use Unix::Time". But make the core language easily
accessible to everyone. That's where mjdate() comes in, IMO.

-Nate

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Russ Allbery]

Tim Jenness <[EMAIL PROTECTED]> writes:

> Of course, "seconds since 1970" is only obvious to unix systems
> programmers.

I disagree; I don't think that's been true for a while.  It's certainly
familiar, if not obvious, to *any* Unix programmer (not just systems
programmers), as it's what time() returns, and pretty much any C
programmer will have used that at some point or another.  It's also so
widespread as to be at least somewhat familiar to non-Unix programmers.

Anyway, it doesn't matter; it's a lot more widely used than any other
epoch, and epochs are completely arbitrary anyway.  What's wrong with it?

> MJD is doable with current perl 32bit doubles. I use it all the time in
> perl programs and am not suffering from a lack of precision.

Day resolution is insufficient for most purposes in all the Perl scripts
I've worked on.  I practically never need sub-second precision; I almost
always need precision better than one day.

If we're aiming at replacing time, it has to provide *at least* second
precision, at which point I really don't see the advantage of MJD over
Unix time.  Why change something that works?

Is Perl currently using different epochs on different platforms?  If so, I
can definitely see the wisdom in doing something about *that* and
off-loading the system-local time processing into modules (although I can
also see the wisdom in leaving well enough alone).  But why not go with
the most commonly used and most widely analyzed epoch?

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Tim Jenness]

On 14 Aug 2000, Russ Allbery wrote:

> Nathan Wiger <[EMAIL PROTECTED]> writes:
> 
> > The idea would be twofold:
> 
> >1. time() would still return UNIX epoch time. However, it
> >   would not be in core, and would not be the primary
> >   timekeeping method. It would be in Time::Local for 
> >   compatibility (along with localtime and gmtime).
> 
> >2. mjdate() would return MJD. It _would_ be in core, and
> >   it _would_ be the internal timekeeping method. All
> >   of the new date functions would be designed to be based
> >   off of it.



> 
> By comparison, who uses MJD?  Practically no one.  It's a theoretically
> nice time scale, but outside of the astronomy community, how many people
> even have any idea what it is?
> 

In one of my previous posts I was simply suggesting that the Date object
(whatever it is) should have a method to return the internal format
(seconds, mjd, whatever) to allow for simple date arithmetic without
having to do anything more complicated. unix seconds and mjd both will
allow this.


> This appears to be a proposal to replace a *very* well-known time base
> with very well-known and commonly-used properties with a time base that
> practically no one knows or currently uses just because some of its epoch
> properties make slightly more sense.  Unless I'm missing something
> fumdamental here, this strikes me as a horrible idea.

Of course, "seconds since 1970" is only obvious to unix systems
programmers. "Number of days since XXX" is just as valid for someone
coming to the language from a different direction and at least has some
kind of basis outside of computing.

> 
> Unix's time representation format has no fundamental problems that aren't
> simple implementation issues.  Negative values represent times before 1970
> just fine.  The range problem is easily solved by making it a 64-bit
> value, something that apparently we'd need to do with an MJD-based time
> anyway.  And everyone already knows how it works and often relies on the
> base being consistent with their other applications.
> 

MJD is doable with current perl 32bit doubles. I use it all the time in
perl programs and am not suffering from a lack of precision.

In fact RFC #7 ("Higher Resolution time values") suggests that the
concept of "number of seconds since epoch" will have to make room for
fractions of a second anyway.

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Russ Allbery]

Nathan Wiger <[EMAIL PROTECTED]> writes:

> The idea would be twofold:

>1. time() would still return UNIX epoch time. However, it
>   would not be in core, and would not be the primary
>   timekeeping method. It would be in Time::Local for 
>   compatibility (along with localtime and gmtime).

>2. mjdate() would return MJD. It _would_ be in core, and
>   it _would_ be the internal timekeeping method. All
>   of the new date functions would be designed to be based
>   off of it.

Here's the significant problem that I have with this:  It feels very much
like it's putting the cart before the horse.  Perl is fundamentally a Unix
language (portable Unix, to a degree).  It's core user base has always
been sysadmins and hackers with a Unix-like mindset, regardless of the
platform they're using.  As an example, I've written literally hundreds of
scripts that use Unix time in one way or another; it has innumerable
really nice properties and is compatible with all the other programs
written in other languages that I have to interact with.

By comparison, who uses MJD?  Practically no one.  It's a theoretically
nice time scale, but outside of the astronomy community, how many people
even have any idea what it is?

This appears to be a proposal to replace a *very* well-known time base
with very well-known and commonly-used properties with a time base that
practically no one knows or currently uses just because some of its epoch
properties make slightly more sense.  Unless I'm missing something
fumdamental here, this strikes me as a horrible idea.

Unix's time representation format has no fundamental problems that aren't
simple implementation issues.  Negative values represent times before 1970
just fine.  The range problem is easily solved by making it a 64-bit
value, something that apparently we'd need to do with an MJD-based time
anyway.  And everyone already knows how it works and often relies on the
base being consistent with their other applications.

It really doesn't sound like a good idea to change all that.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Bryan C . Warnock]

On Mon, 14 Aug 2000, Nathan Wiger wrote:
>1. time() would still return UNIX epoch time. However, it
>   would not be in core, and would not be the primary
>   timekeeping method. It would be in Time::Local for 
>   compatibility (along with localtime and gmtime).
> 
>2. mjdate() would return MJD. It _would_ be in core, and
>   it _would_ be the internal timekeeping method. All
>   of the new date functions would be designed to be based
>   off of it.
> 
> So, just to clarify:
> 
>1. The Perl 5 way in Perl 6:
> 
> use Time::Local;
> $date = localtime time();
> 
>2. The Perl 6 native way:
> 
> $date = date mjdate();

Now, are we talking about the new default/de facto standard that the
users are being presented with?  Or are we talking about the true
internal structure?  ("and it _would_ be the internal timekeeping
method.")

I don't have an OS that reports time in MJD.  It seems
counter-productive (IMHO) for Perl (internally) to convert from
whatever the native platform time measurement is to MJD, only to
convert it back to the native format again, if that never is presented
to the users.

For example:

# From 5.6 perlfunc
$now = time;
utime $now, $now, @ARGV;

Under this proposal, time would (under Unix), return the number of
epoch seconds, which would then be converted to MJD internally.  This
stored MJD would then have to be converted back to the original epoch
seconds, (perhaps twice), for the argument to utime?  Alarms and
timers, file tests - any time interface outside of Perl itself - these
*all* will be converted to MJD internally?

(Assuming, of course, that you don't explicitly change the arguments to
utime to accept MJD, although it would still have to be converted to
native format anyway.)

I can understand wanting to present the user with a common,
multi-platform, consistent date/time interface, but I don't understand
extending that to the internals.

 -- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Nathan Wiger]

> > I'm not sure anyone does that much in the way of time/date work that it'd
> > make a difference. Besides, we're talking internal here--time() may still
> > return Unix epoch seconds for compatibility reasons.
> 
> Blah!  I saw the prosal for an mjdate() routine and thought it was at
> the language level for some reason.  This RFC should go to -internals
> so that I don't get confused that way  :-)

Hey wait, you're both right! :-)

The idea would be twofold:

   1. time() would still return UNIX epoch time. However, it
  would not be in core, and would not be the primary
  timekeeping method. It would be in Time::Local for 
  compatibility (along with localtime and gmtime).

   2. mjdate() would return MJD. It _would_ be in core, and
  it _would_ be the internal timekeeping method. All
  of the new date functions would be designed to be based
  off of it.

So, just to clarify:

   1. The Perl 5 way in Perl 6:

use Time::Local;
$date = localtime time();

   2. The Perl 6 native way:

$date = date mjdate();

Make sense?

-Nate