How the Hebrew calendar generator computes candle lighting and tzeit hakochavim

Why the year runs Tishrei through Elul, and how that boundary is found without recalculating anything

The Hebrew calendar's own year boundary is Rosh Hashanah, the first of Tishrei, not January 1st. A calendar built for people who think in Hebrew-year terms should follow that structure natively rather than forcing it into twelve Gregorian-month pages that split every Hebrew month across two calendars. The general Calendar Generator's existing per-day dataset already maps every Gregorian date from 2020 through 2036 to its Hebrew day, month, and year, so finding "everything in Hebrew year 5786" doesn't need new data or new date math: it's a filter over dates already tagged with that year, sorted chronologically. Group consecutive same-month entries and the month boundaries, including exactly where Adar splits into Adar I and Adar II in a leap year, fall out of the grouping for free. The only real constraint is the data's edges: a Hebrew year is only fully usable if the day before its first date and the day after its last date both exist in the dataset, which rules out the very first and very last partial years in range and leaves 16 fully usable Hebrew years.

Why a typed Gregorian year resolves to a two-year range instead of a single year

Every Hebrew year spans two Gregorian years, Rosh Hashanah lands somewhere in September or October, and Elul of the same Hebrew year doesn't finish until deep into the following Gregorian year. Silently picking one side of that split would be actively misleading, so typing a Gregorian year resolves to the Hebrew year whose Rosh Hashanah falls in that typed year, and the result is always shown as the full range, "2026-2027," never a bare "2026," with a plain-language line explaining that the calendar starting in the first year continues into the second. Under the hood this is the same kind of lookup as the year-boundary logic above: scan the per-day dataset for the Tishrei-1 entry that falls in the typed Gregorian year and read off its Hebrew year. Both entry points, typing a Hebrew year directly or typing a Gregorian year, feed the same single "build this Hebrew year" function; the two pickers are just different doors into the same room.

Why candle lighting and tzeit hakochavim are computed live instead of baked like the holiday data

Every other date on this site gets computed once, offline, and shipped as a static file, because holiday rules and Hebrew-calendar math are genuinely complex enough to need a real library, and they don't depend on the visitor. Sunset breaks that pattern: it's a function of a specific latitude, longitude, and date, and the location is only known once someone picks it in the browser. Baking sunset times for every date and every possible location isn't just impractical, it's the wrong shape of problem, since the actual computation, given a date and coordinates, is fast, well-understood astronomy that runs in a few milliseconds. So this is the one piece of calendar math in the entire Orisod PDF-tool lineup that happens live in the browser rather than being looked up in a pre-built table: a small solar-position library computes sunset for the chosen location on every Friday and Saturday in the selected Hebrew year, and candle lighting and tzeit hakochavim are both offsets from that single sunset time.

Why there are two different ways to define tzeit hakochavim

Tzeit hakochavim, the emergence of the stars that marks when Shabbat or a holiday ends, doesn't have one universal definition. Some communities define it as a fixed number of minutes after sunset, commonly 42, 50, or 72 depending on custom. Others define it astronomically, as the moment the sun reaches a specific angle below the horizon, commonly 3.7, 4.61, 6.5, or 8.5 degrees. These aren't two approximations of the same number: at a given location and time of year they can diverge by a meaningful margin, and picking one over the other isn't a UI simplification this tool should make on anyone's behalf. Both modes are offered side by side, computed from the same sunset calculation, so switching between them is a single dropdown, not a different feature.

Why location has three input paths, and why manual coordinates need their own timezone picker

Sunset time needs a location, but "give me your coordinates" is a bad first ask for most people. City search covers the common case: picking a city looks up its stored latitude, longitude, and time zone in one step, no ambiguity. Browser geolocation covers the case where someone wants their exact current position: the device already knows its own time zone, since geolocation implies physical presence there, so that value can be reused directly. Manual latitude and longitude exists for the remaining case, someone checking a location they aren't physically at and that isn't in the city list, and that's exactly the case where the time zone can't be inferred from anything else available client-side: there's no bundled dataset mapping arbitrary coordinates to time zones without pulling in a much heavier geo-boundary library, so manual entry gets its own explicit time zone picker instead of guessing.

Where the weekly Torah portion comes from

Parashat HaShavua follows a fixed annual reading cycle, but it isn't simple date arithmetic: combined portions like Vayakhel-Pekudei split apart or merge depending on the Hebrew leap-year cycle, and any Shabbat that falls on a major holiday gets that holiday's special reading instead of the regular weekly portion. That's exactly the shape of problem the site already solves by baking a dedicated calendar library's output into a static file: a perpetual Hebrew-calendar library computed every Saturday's portion name for the same 2020-2036 range as the rest of the calendar data, once, offline, matching the Diaspora annual reading cycle. A Saturday with no entry in that file is a holiday-reading Shabbat, and the day's own holiday name, already shown from the general calendar data, covers it instead.

Quick answers

Do I need to pick a location just to see the Hebrew calendar? No. Holidays, Hebrew dates, day shading, and the weekly Torah portion all show without one. Location only gates candle-lighting and tzeit hakochavim times.

Why does the tool warn that these times are estimates? Because they are: a calculated sunset time is a reasonable reference, not a religious ruling, and small differences near a coastline, at high latitude, or between calculation methods are normal. Confirming with a rabbi or local community practice is the actual authority here.

Can I still add my own photos and custom events, like on the general Calendar Generator? Yes, both work exactly the same way, just against Hebrew months instead of Gregorian ones.

Is any of this uploaded anywhere? No. Location lookup, the sunset calculation, and PDF generation all happen locally in the browser, the same as everywhere else on this site.

The short version: the year follows Tishrei because that's the calendar's own native boundary, and that boundary comes for free out of data the site already has; sunset-dependent times are the one piece of calendar math computed live instead of baked, because the visitor's location can't be known in advance; tzeit hakochavim gets two real definitions instead of one simplified default, because neither is universal; and the weekly Torah portion gets the same dedicated-library treatment as every other piece of Hebrew-calendar math on this site, because it deserves a real implementation, not an approximation.