For interest:

Code:

{Gregorian Calendar} {plots the Gregorian date for the bar at 12:00:00 using the US Naval Observatory algorithm} {User can choose an epoch} {coded by: metastock@wabbit.com.au} epoch:=Input("Epoch: [0] 0, [1] 1 Jan 1900, [2] 1 Jan 2000",0,2,1); epoch:=If(epoch=0,0,If(epoch=1,2415021,2451545)); excel:=Input("Match to Excel, [0] No, [1] Yes",0,1,0); a:=Int((14-Month())/12); y:=Year()+4800-a; m:=Month()+(12*a)-3; g:=DayOfMonth()+Int((2+153*m)/5)+(365*y)+Int(y/4)-Int(y/100)+Int(y/400)-32045; correction:=excel*((Year()>1900 OR (Year()=1900 AND Month()>=3))+1); {plot/return} g-epoch+correction;

If you are going to export these Gregorian Calendar dates to Excel, remember:

• choose the 1900 epoch.  Excel wil not format dates prior to 01 January 1900 so be careful, and
• choose the Excel correction.  There is one day difference in the Gregorian calendar and Excel for all dates before 28 February 1900 and two days difference after that date.  (the reasons for this are widely available on the net)
  

If you just want the true Gregorian date, choose the zero epoch and do not choose the Excel correction.


Hope this helps.

wabbit

---

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim."
Edsgar W. Dijkstra

 

MS: 6.52 EOD, 7.x EOD, 8.0 PRO, 9.2 PRO w/QC, 10 PRO w/QC C, 11 PRO w/QC & MDK
For custom MetaStock programming : http://www.wabbit.com.au
My SkyPE status :
My SkyPE account : wabbit.com.au

The above code is not exactly a Gregorian Calendar with dates output - it is a calendar day counter (or day accumulator).

Original and accurate Calendar Day counter indicator - counts calendar days from any given year.

Of further interest:
Event date indicator - plots yymmdd date in three formats, at customizable event signals.


jose '-)

---

MetaStockTools.com

To be completely precise about what the code does, the US Naval Observatory offers for their algorithm the following information:

http://aa.usno.navy.mil/data/docs/JulianDate.html:

Julian dates (abbreviated JD) are simply a continuous count of days and fractions since noon Universal Time on January 1, 4713 BCE (on the Julian calendar). Almost 2.5 million days have transpired since this date. Julian dates are widely used as time variables within astronomical software. Typically, a 64-bit floating point (double precision) variable can represent an epoch expressed as a Julian date to about 1 millisecond precision. Note that the time scale that is the basis for Julian dates is Universal Time, and that 0h UT corresponds to a Julian date fraction of 0.5.

It is assumed that 7-day weeks have formed an uninterrupted sequence since ancient times. Thus, the day of the week can be obtained from the remainder of the division of the Julian date by 7.

Calendar dates — year, month, and day — are more problematic. Various calendar systems have been in use at different times and places around the world. This application deals with only two: the Gregorian calendar, now used universally for civil purposes, and the Julian calendar, its predecessor in the western world. As used here, the two calendars have identical month names and number of days in each month, and differ only in the rule for leap years. The Julian calendar has a leap year every fourth year, while the Gregorian calendar has a leap year every fourth year except century years not exactly divisible by 400.

This application assumes that the changeover from the Julian calendar to the Gregorian calendar occurred in October of 1582, according to the scheme instituted by Pope Gregory XIII. Specifically, for dates on or before 4 October 1582, the Julian calendar is used; for dates on or after 15 October 1582, the Gregorian calendar is used. Thus, there is a ten-day gap in calendar dates, but no discontinuity in Julian dates or days of the week: 4 October 1582 (Julian) is a Thursday, which begins at JD 2299159.5; and 15 October 1582 (Gregorian) is a Friday, which begins at JD 2299160.5. The omission of ten days of calendar dates was necessitated by the astronomical error built up by the Julian calendar over its many centuries of use, due to its too-frequent leap years.

The changeover to the Gregorian calendar system occurred as described above only in Roman Catholic countries, however. Adoption of the Gregorian calendar in the rest of the world progressed slowly. For example, for England and its colonies, the change did not occur until September 1752. (The Unix cal command for systems manufactured in the U.S. reflects the 1752 changeover.)

Hope this helps.

wabbit

---

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim."
Edsgar W. Dijkstra

 

MS: 6.52 EOD, 7.x EOD, 8.0 PRO, 9.2 PRO w/QC, 10 PRO w/QC C, 11 PRO w/QC & MDK
For custom MetaStock programming : http://www.wabbit.com.au
My SkyPE status :
My SkyPE account : wabbit.com.au

Wabbit, thanks for bringing your military-precision background into the MetaStock domain. ;)

I'm not sure where you are heading with this, but be aware that MetaStock can only plot/calculate dates between 1800 and 2200, so any day count prior to Wed 1st Jan 1800 (75,748 days ago) is irrelevant in MetaStock.

Talking about precision:

plots the Gregorian date for the bar at 12:00:00

Your code only works at noon? What about 11:59:59am or 12:00:01pm? :)


jose '-)

---

MetaStockTools.com

Thanks for the feedback Jose,

I developed this code so that dates after 1900 but before before 2000 could be properly dealt with by Excel when cutting and pasting data from MS charts into Excel.  (I later learnt that Excel has some serious date issues, hence the limit for 1900 and the correction factors.  <sarcasm>Thanks Mr W. Gates et. al. </sarcasm> )

If you want to export, say the Dow Jones to Excel (or any other instrument that has data prior to 01 Jan 1900) then you have other problems in Excel that have to be dealt with differently, in addition to any limts from MetaStock.  ( Curiously Access does not have the same troubles as Excel when it comes to dates?  It has some of its own issues that are different from Excel?! )

The 12:00:00 UT/GMT factor is to align the values with the MS date with the correct Julian / Gregorian data for that date:

For example:
The date is 24 May 2007.  The JD for (let's pretend time is GMT/UT for simplicity):
00:00:00 24 May 2007 is 2454244.5
08:00:00 24 May 2007 is 2454244.83333
11:59:59 24 May 2007 is 2454244.99999

12:00:00 24 May 2007 is exactly 2454245
( neat pattern for 24/5 don't you think? 245 4 245 on 24/5? )

12:00:01 24 May 2007 is 2454245.00001
16:00:00 24 May 2007 is 2454245.16667
etc. (5dp)

I think(?) most people don't need the precision of the time of day, so I chose the arbitrary time for the JD as 12:00:00 GMT/UT so the indicator returns integer values only.  It also means that after making the necessary corrections for Excel, the JD for 24 May 2007  returned by the MS code (39226) is interpretted correctly by Excel for the date (24 May 2007) Excel will show the time as 00:00:00 so if users are concerned with attaining this level of precision with the data they export to Excel, they should add 0.5  (Personally, I am happy keeping the integer values.  It also allows for the correct computation of the day of the week by taking the modulo 7, and this can be used to count weeks too.  Computing the month, or month and year from the JD is a little harder.)

I suppose to be abolutely precise, individuals should also adjust for the time zone of the exchange for which the data is being presented?  I didn't bother with that as I assume that most users will be happy to take the date as given in their data.

I subtract the epoch of 01 Jan 1900 for export to Excel purposes, or 01 Jan 2000 to keep the JD number small for "ease of use" in MS, but keep the "zero" epoch for precision and checking of the algorithm against the USNO site.  (If somone needs to amend the code to include 01 January 1800 epoch, the correction factor is 2378497)

If members need the precise JD to align their trading with the moon or stars etc, just add/subtract the proportion of the day in time as a decimal to/from the days as an integer.  Or, let's put it like this:  here is some code that members can take for themselves and manipulate as required to take the date-time data from MS into whatever application they like.  If anyone needs any help implementing this, just ask, there are too many variables for me to cover in one piece of (meant to be simple : KISS) code.



Hope this helps

wabbit

---

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim."
Edsgar W. Dijkstra

 

MS: 6.52 EOD, 7.x EOD, 8.0 PRO, 9.2 PRO w/QC, 10 PRO w/QC C, 11 PRO w/QC & MDK
For custom MetaStock programming : http://www.wabbit.com.au
My SkyPE status :
My SkyPE account : wabbit.com.au

Ouch... my head is spinning after that KISS-type explanation. ;)

For anyone who prefers to keep it even simpler (i.e., forget about GMT/UT time zones, and let the data's date stamp take care of the calendar day in question):

{plot/return}
Int(g-epoch+correction+0.5)

Now, where did I put that original Tulip mania data set?


jose '-)

---

MetaStockTools.com