# Template talk:MJD

Add topic## Documentation[edit]

For more test cases and a detailed documentation see:

- template:MJD (edit•talk•links•history) (year month day hour minute second)
- template:YMD2MJD (edit•talk•links•history) (year month day)
- template:Dectime (edit•talk•links•history) (hour minute second)
- template:Timestamp2MJD (edit•talk•links•history) (current timestamp)
- template:MJD2sec (edit•talk•links•history) (POSIX timestamps)

- Time interval example:
- {{DHM| {{MJD|2006|6|1|2}} - {{MJD|2006|5|30|21|30}}}} gives
**1 d 01.1875:30** - {{DHM| {{MJD|2006|1|8|21|30}} - {{MJD|2004|12|30|2}} }} gives
**374 d 14.8125:30**

## Discussion[edit]

*Add issues below as you see fit, sign with*~~~~

### Calendar issues[edit]

It's probably a bad idea to extend YMD2MJD before 0000:03:01. The Rata Die algorithm for the opposite direction doesn't work BC, the test suite doesn't cover it, and the Gregorian calendar is never used before that "day -306". JD switches to Julian leap years BC, and MJD inherits that switch if you extend it backwards.

The formulae get much more convoluted (although Julian mod 4 leap years are simpler), because rounding goes in the opposite direction. It's the design idea of this template to produce results known to work for Rata Die, and to use no other template - my original YMD2MJD/2 plan was a horrible idea. -- Omniplex (w:t) 20:12, 31 May 2006 (UTC)

- Convenient about a proleptic calendar is that you just extrapolate; it is odd to make an unneeded restriction. I modified the formula so that it rounds in the correct direction regardless of the sign of the year.

- What do you mean by "JD switches to Julian leap years BC"? JD just counts days, it is not associated with any system of leap days.--Patrick 12:23, 1 June 2006 (UTC)

- So far I didn't look into the new code, only at the results: Something with the "negative" leap years is odd, see Template talk:YMD2MJD "new tricks", apparently
**off by one**(-3 as leap year instead of -4, 0 unclear, -100 and -400 missed, maybe they'd show up as -99 and -399).

- So far I didn't look into the new code, only at the results: Something with the "negative" leap years is odd, see Template talk:YMD2MJD "new tricks", apparently

- {{ YMD2MJD|-003|02|28 }} = -679978, last day February 4 BC
- {{ YMD2MJD|-003|03|02 }} = -679976,
- Looks fine, no leap year, 2 days later.--Patrick 15:11, 1 June 2006 (UTC)

- The Julian issue is -100 (or maybe -99 at the moment), AFAIK Julian Dates (and therefore also MJD) use "Julian" (the other, Caesar) modulo 4 leap years BC.

- The stated purpose of the template is to convert Gregorian and proleptic Gregorian calendar dates, so -100 is no leap year. That has to do with the proleptic Gregorian calendar, not with the very simple JD system (not to be confused with the Julian calendar).--Patrick 15:28, 1 June 2006 (UTC)

Gregorian would skip -100 / -200 / -300. For -400 they'd agree, that's a leap year. I'm also not sure about your MJD -2400001 result for JD 0, that's something for template:MJD (edit•talk•links•history), the real result should be -2400000.5.

- The template gives the MJD at 0:00, so 0.5 less than at noon.--Patrick 15:46, 1 June 2006 (UTC)

If what I think is correct you'd end up with a split formula: Simple Julian BC, Gregorian corrections starting in year 100, year 0 (1 BC) TBD, at the moment your formula gives "no leap year" 0000-02-29 = 0000-03-01.

- IsLeapYear 0 says 1. Probably Locke never expected such weird applications, that's no proof, only a fact. What we desperately need to get it right for negative dates are reliable sources how astronomers really handle this. Minor problem, both Gregorian and Julian calendar didn't exist BC, if they had leap days at all it was elsewhere (e.g. counting one day in February twice, no 29). So the dates are kind of pointless anyway, but the number of days per year is important, otherwise you could be off by centuries for huge negative day numbers.
- For the opposite direction (MJD to calendar date) it's clear, "Rata Die" doesn't work BC, it's a simplification of the Gregorian + Julian algorithms allowing negative dates with dubious (= different) results. Negative years in calendar dates have other undesirable effects, some ISO formats designed for yyyy-mm-dd, yyyymmdd, or similar result in gibberish if a hyphen-minus pops up. It's a can of worms.
- How about moving that section to either the MJD or the YMD2MJD talk page? I only started it here yesterday because the system was excessively slow and I wanted to alert you as fast as possible about this "can of worms". -- Omniplex (w:t) 14:59, 1 June 2006 (UTC)

- While it's still here, the "identical from 200 to 300" (not -99 to +99) explains the last issue, either the switch has to come in this period (replacing one <0 by <200), or better it stays where it is counting year 0 not as leap year (it wasn't in reality), then the JD 0 result should work (like all other BC dates where they are used at all).
- With that the opposite direction could use RD later for the common era (doesn't work BC, so that's okay), Julian for negative ISO years (for BC dates in literature), and 365 days in year 0 to get the synchronisation earlier. Assuming that it really is
**off by one**at the moment. I'll think about that tomorrow. - For
**relevant**dates see`{{MJD}}`

, we've already beaten POSIX seconds and JD wrt accuracy, 1/100 seconds work... :-) -- Omniplex (w:t) 12:51, 2 June 2006 (UTC)

- It was off by 2, I corrected it.--Patrick 13:09, 2 June 2006 (UTC)

- Okay, with an odd gap. We could get the "missing" two days by declaring 100 and 200 CE to be leap years, you found a justification for that, it's calibrated to be in sync for 200..300 CE. Minor disadvantage, ISO wants Gregorian dates, and "use ISO for CE" is slightly more plausible than "use ISO starting in year 200". But no gap is also more plausible than two days lost in space.
- The DOW formula probably won't work for "missing" days. And a MJD2YMD formula claiming that days -678943 and -678942 are illegal would be very odd. At the moment I'd say let's add leap years 100 and 200: If I add or substract 700,000 from any MJD I expect it to be the same weekday, always. -- Omniplex (w:t) 09:34, 7 June 2006 (UTC)

- Ok, using Julian before 250 is fine with me, it is nice for continuity. Note however that currently the inverse functions like Template:MJD2D use Gregorian.

- The relation between MJD and weekday is fixed, and not related to a choice between Julian and Gregorian.--Patrick 23:14, 7 June 2006 (UTC)

- I changed before 250 to Julian.--Patrick 08:11, 8 June 2006 (UTC)

- Excellent, I integrated some missing pieces into the docu. For
`{{MJD2M}}`

etc. it's okay if they differ before March 200, as long as it's documented and we know why. -- Omniplex (w:t) 04:18, 10 June 2006 (UTC)

- Excellent, I integrated some missing pieces into the docu. For

### Auxiliary templates[edit]

I got rid of the two auxiliary templates `{{dectime/2}}`

and `{{YMD2MJD/2}}`

by using their code directly in `{{Timestamp2MJD}}`

. The nested templates made me nervous, because there's no guarantee that a page including **#if: A|B|C** really only looks at either B or C wrt cache / database access. For an explanation of what I did see `{{YMD2MJD/2}}`

. -- Omniplex (w:t) 04:09, 10 June 2006 (UTC)

### Accuracy example[edit]

That new example is actually about **subtractions**, with floating point arithmetic it's always cumbersome if many digits are eliminated. In this example anything before the decimal point (same day) and some digits after it (same hour, same minute) are eliminated. It's a **good** result that it's still accurate down to 1/100 seconds. -- Omniplex (w:t) 02:23, 26 June 2006 (UTC)