Talk:D'ni timekeeping conversion algorithms

From MYSTlore

Jump to: navigation, search

RAWA confirmed with me during Mysterium '06 that the exact length of one hahr is the length of our year 1995 AD (from the beginning of January to the end of December). This length is fixed and they had no leap years, leap seconds or anything else that ever changed the length of the year, also according to RAWA. Now, to find out how long that is exactly, taking into account various leap seconds and other things... — The preceding unsigned comment was added by Riumplus (talkcontribs) 03:33, 18 December 2006. Please sign your comments!

So I suppose that might explain the "1.5" cited by the DRC / the old Cyan website. The year would have been shorter; therefore making prorahntee longer, and perhaps closer to 1.5 than 1.4. Chucker 20:41, 17 December 2006 (CST)


So, given I seem to have studied enough on this topic to become basically a self-proclaimed expert, I thought I should throw my name out there for time-related queries. If any authors of D'ni time things need someone to check their programming for accuracy, you're more than welcome to get in touch with me and I can check it through for you. I can probably answer your question, whether it's software or machinery-related (Yes I can check plans for timekeeping devices for accuracy if you want :P ). I'd prefer it if I'm not constantly barraged with questions for a whole bundle of simple date/time conversions (you can use various conversion software yourself to get the conversions), however, so only message me if it's something slightly more complicated than a simple date/time conversion. And if anyone else can suggest any changes, clarifications or other information that can be included in this article and they don't have the knowledge or time to do so, drop me a line. --RIUM+ 07:19, 5 November 2007 (CST)

I was gonna ask you anyway. So if you want, you could check whether everything sprintfDate() on http://modern-dni.mystlore.com/wiki/MYSTlore:MediaWiki_localization/LanguageMd.php thus far does the right thing™. It's one yahr off compared to CCConverter, but that one uses a different rosetta date.
And, yes, I'd like for the main article to become more of a general hub of how to convert things so people don't have to keep reinventing the wheel. :-) That is, once things are confirmed to be correct, they should be added over there. Chucker 03:04, 6 November 2007 (CST)
You had to be the first person to take up my offer and be using the programming language I detest the most, didn't you? ;P I've looked through it and the first thing that pops out at me is that you're using Unix time, which is fine and dandy if you want to use it but doesn't take into account leap seconds (every time there's a leap second, the counter increments by one slowly over the second, decrements by one and then slowly increments again to make the total count of 'seconds' per day 86,400, even when there's actually 86,401 seconds in that day. View the page on Unix time (Wikipedia) for more info, as well as the one on Leap seconds (Wikipedia)). You'll be 7 seconds too slow for estimates of the current date/time in 2007, but if that's good enough for you then it's fine as-is. Given it seems to be used just to list the current date/time in D'ni Time, you should be able to get away with just skewing the result by 7 seconds and you should be correct until probably at least the end of 2008, where it may (or may not, depending upon the changes of earth's rotation) need to be adjusted to 8 seconds. To make it correct for all date/times you'd need an array of leap seconds and skew it accordingly, but for something designed to only display the current time and not offer conversions of user-inputted times, a simple skew would be fine. Don't forget to synchronise the server's internal clock every few weeks, or else all the accuracy has gone to waste. :)
Hmm, I wonder if I should knock together some graphic of a big, rubber stamp of approval saying the conversion stuff in this software has been checked for accuracy, and list that program's estimated accuracy... some Guild of Horologists symbol or something, heh.— The preceding unsigned comment was added by Riumplus (talkcontribs) 11:08, 6 November 2007. Please sign your comments!
Hey, I'm definitely no fan of PHP at all. The language is hack-ish at best, and the API has many non-uniform peculiarities.
I think the stamp of approval is actually a good idea.
So you think my yahrtee are in fact calculated correctly? Does that mean CCConverter (which gives one yahr more for the current date) is wrong, or are its calculations merely somewhat off due to the different rosetta date? (But… an entire yahr?!)
Gotcha about the leap seconds. In the long run, I'd like to account for them, but I'm not quite sure yet how to do so in a way that isn't completely ugly… and slow. :-)
Thanks for the feedback. And yes, when you offer something, I'll take it up. :-p Chucker 04:44, 6 November 2007 (CST)
I didn't check the multiplication perfectly as I'm not the best at PHP, but there's an easier way than me checking the code directly in this case to check if that long stream of multiplications is correct. Is there a version somewhere I can run that I can parse a value to use as the 'current' time? That would be the easier than me trying to wade my way through the PHP, and I can perform the calculations manually to check on some of the edge-cases and if it fails, I can then wade through the code. The fact that it's a year off might be an issue though, as from what I recall with speaking with BrettM, he was using a rosetta date that was only a few seconds off from the actual one iirc. But it's easier for me to check for consistency with a version that's running as well as the code behind it, and my server's all configured to run the Riven Journals so I can't run anything custom on there really. ;P
Hmm, who to contact about knocking together a Guild of Horologists stamp since I have zero graphical capabilities... Any suggestions there? --RIUM+ 06:10, 6 November 2007 (CST)
No, it's a yahr (≈day) off, not a hahr (≈year). CCConverter and my code agree on the hahr and vailee (≈month), but not on the yahr. I haven't checked for hours and minutes yet, but being an entire day off is still quite strange.
The CCConverter help files, however, state that they use a rosetta date based on the Riven Journals site: Leefo 1, 9654 DE 00:00:00:00 DT = April 21, 1998 CE 10:35:18 UTC. So it's 9647 vs. 9654, 1991 vs. 1998 and 17:54 vs. 10:35. I don't know if it's possible that the two timekeeping systems happen to converge at both dates, but I assume not. (Not trying to criticize Brett, by the way; his app is cool. I'm just not sure if it's accurate enough to be a benchmark for me.)
I contacted Tweek about the stamp, but no response yet. I'll get back to you on that. I'll also see about writing you a version of the above routine where you can easily just pass the current timeestamp (or one of your choice). Hopefully later this week. Chucker 06:51, 6 November 2007 (CST)
You've got mail regarding the stamp.
Also, as you were hoping, I've added a way of inputting arbitrary timestamps. Just head on over to MYSTlore-MDni (you don't need an account nor an actual article; MYSTlore:Sandbox and an anonymous edit will do, although you don't even really need to submit; just use the preview function).
Then, use something like <d'nidate format="Y-m-d">20071106123456</d'nidate>. The format argument takes the parameters from http://php.net/date as well as some additions we currently don't use (for instance, MediaWiki can account for a genitive form of month names). The timestamp is not Unix (as you can probably tell) but actually just YYYYMMDDHHMMSS. It has to be that exact length (14 characters), so you have to include everything from four-digit year to two-digit second, or else you'll get odd results. Chucker 14:33, 7 November 2007 (CST)
As for the off-by-one yahr, it appears that was a rounding error that I have since fixed. CCConverter both report today as 23 Leevofo 9663. Chucker 17:32, 18 November 2007 (CST)
Personal tools