HP3000-L Archives

January 2001, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Shawn Gordon <[log in to unmask]>
Reply To:
Shawn Gordon <[log in to unmask]>
Date:
Wed, 31 Jan 2001 11:25:24 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (74 lines)
At 10:12 AM 1/31/2001, Ric Merz wrote:
>Common usage sometimes creates new meanings.  When I was growing up it was
>said that "ain't" ain't in the dictionary.  (I never looked it up at the
>time.)  Now ain't is very popular.
>
>Even though the offical Julian version (see web site, thanks Wirt) is
>different, the HP Calendar intrinsic returns it as YYDDD.  So 01/31/01 is
>101031.  (BTW, the Calendar intrinsic is Y2K27 compliant.  I hope HP fixes
>it before the last minute.)

they did, it's called HPCALENDAR and they expect you to use it instead of
CALENDAR if you want it to work past 2027.

>However, even more important to common communication: Look at just about
>any desk calendar and you will find a day count based on the day number of
>the year.  Most people I know refer to this as the Julian day.  It might
>not be 100% correct, but a lot of non-computer people use it.
>
>So if my client says he wants the Julian day on a report, I will
>automatically setup a 3 digit field, not a 7 or 8 digit field.
>
>
>
>At 09:37 AM 1/31/2001 -0800, you wrote:
> >Good question.
> >I think all are correct in a loose definition.  Which is to say, a number of
> >days since a given date in the past.  It's just that some folks decided to
> >start their count much earlier, yet I agree, one representation of the
> >julian, is the year + the 3 digit number.  But you cannot use this to add or
> >subtract dates.  Therefore, they use the other representation, to find out
> >the number of days since a given date, then use an algorithm to convert it
> >into a date-readable format such as yyyymmdd.
> >
> >I look forward to what others have to say about this.
> >
> >Paul wrote:
> >> today someone asked me what the Julian date was for today; I
> >> replied 01031, with
> >> tomorrow
> >> being 01032, etc.   Another person said that's not what a
> >> Julian date is at all,
> >> and upon looking it
> >> up on a web site - one site says it is 2451941 another site
> >> defined Julian date
> >> as the number
> >> of days since Jan 1, 4713 BC and that today is 1757966.
> >>
> >> Of course neither of these two answers fit my definition of a
> >> Julian date.
> >>
> >> So why does my COBOL manual state that a function can convert
> >>  to Julian date
> >> form
> >> (YYYYDDD) and shows that today would be 2001031 (newer
> >> manual, now uses the 4
> >> digit year,
> >> whereas I in my olden days ways, still think of a Julian date
> >> as YYDDDD).
> >>
> >> Has my COBOL manual been lying to me all these years??
> >>
> >
>Ric
>[log in to unmask]


Regards,

Shawn Gordon
President
theKompany.com
www.thekompany.com
949-713-3276

ATOM RSS1 RSS2