bchurchill/badi-cal

A javascript library for Badi calendar conversions.

badi-cal's Issues

setup continuous integration for deploying gh-pages branch

(self-explanatory)

Retire v1 API

The V1 API is (probably) only used for the example code, so we could reasonably refactor it into the example itself and not need to worry about maintaining it.

Converting 'Date' to 'BadiDate'

Hey. So I'm not sure if I have run into an issue or it's just my lack of understanding but I think there is something wrong. When I run the following:

var todayDate = new Date();
var todayDateBadi = new BadiCal.gregorian_to_badi(todayDate);
console.log(todayDate, todayDateBadi.toString(), BadiCal.find_naw_ruz(todayDate.getUTCFullYear()))

on my machine I get:

Thu Jun 25 2015 05:36:33 GMT-0600 (CST) "2 Raḥmat 172" Fri Mar 20 2015 18:00:00 GMT-0600 (CST)

but when I run it on a device with its location settings set to NZ timezone I get:

Thu Jun 25 2015 23:37:09 GMT+1200 (NZST) "2 Raḥmat 172" Sat Mar 21 2015 13:00:00 GMT+1300 (NZDT)

The sunset time for today in NZ was 5:12pm so shouldn't it be returning "3 Rahmat 172"?

Find Days

Maybe I'm using this wrong but the results here don't look right as Bahá is missing. Thoughts?

Create a Gregorian Date Component Class

• There are semantic issues with the provided Date class in js
• It would be more clear and better suited to have an alternative Gregorian Date Component, which can be used to represent a gregorian date

Variable names

As far as I can tell, we only store two kinds of values in a javascript Date object:

• The time of a fixed astronomical event (in UTC). This might be a moment of sunset, the moment of a new moon, the spring equinox, or so on.
• A gregorian day at a fixed time (e.g. midnight).
• In some cases we store both kinds of values in one variable at different times (e.g. when computing the new moons)

I think we should use different names for the first two kinds of variables (e.g. utcFoobar or dateFoobar), and introduce new variables to account for the third kind. This would certainly be an improvement over the original variable names, which admittedly aren't that informative. We can do something similar for function names.

As an example, this was partially done in find_naw_ruz in the old code, where some variables ended with _day and others ended with _utc. But that wasn't systematic. What would actually be really ideal is to rewrite the code with a different type for a gregorian day (e.g. month/day/year) and only use Date objects for UTC. I don't know if doing that refactor is worth it though.

As far as I can tell there are no other "types" of variables where we store time, but if for some reason we ever stored something with localtime we might name that variable differently.

printable calendar view

It would be nice to make a utility like the UNIX cal utility that prints out the current month in a calendar format and highlights the current day. I could imagine running such a utility on a machine via NodeJS. Or maybe it's time to switch languages...

documentation updates

A few more documentation updates:

• Create a style guide corresponding to what's in the repository now
• Create a guide that simply documents what the functions of the public API do

create string output with custom format

Many date/time libraries will have a format() method that takes a string containing escape sequences, and then format the date according to that string. We might want, for example, escapes like this for this library:

%d  day of the month
%m  month
%y  year
%w  name of weekday
%H  hour
%M  minute
%S  second

Sunset time based on current location

On reddit you mentioned that you're planning on doing this at some point but I was just wondering is it similar to the tehran_sunset function but just needs to be passed the lat/long of the location and then converted to local timezone?

Internationalization

There is some request to be more consistent in showing the Gregorian dates across other languages. See http://www.reddit.com/r/bahai/comments/34ly9c/badi_calendar_app_feedback_appreciated/crr5mex. This might combine with #1 since I think the locale affects if weekdays are shown.

Caching

Right now, every date is computed from scratch. One nicety is that we can compute provisional dates for future years based on the 10 July 2014 letter, but there are some downsides:

• Client-side performance might suffer.
• Subtle bugs in the browser's javascript interpreter could cause erroneous dates. This isn't very likely, but it could happen after an urgent security update, for example. Javascript isn't very good at being reliable across platforms.

So, a totally reasonable thing to do would be to cache the computed values for all the years corresponding to the official dates provided by the Baha'i World Center. This offers two obvious advantages:

• The client will be much faster
• We can be 100% assured that the dates will match the official ones, even if there are subtle bugs in the client-side javascript interpreter (e.g. floating point arithmetic mistakes).

Day of the week

I might have overlooked it but is there a way to get the day of the week at the moment? i.e. Istiqlál

.jshintignore, .jshintrc

After running npm run clean-build and npm run create-build there were two new files created, .jshintignore and .jshintrc. I don't know the best practice for handling these files in version control (or what they do, frankly), so perhaps we can decide if they should be added to the .gitignore or committed into the repository?

migrate test suite from example2 (harness) to unit test infrastructure

(should be self-explanatory)

Leap year

Does badi.js take leap years into account? i.e. if looking for when Naw Ruz is next year is badi.js taking into account that next year is a leap year?