A Time That Depends on Where the Product Is Standing

Any product that acts on Shabbat, Jewish holidays, or daily prayer times has to know when those times begin and end, and none of them are clock times. They are derived from the position of the sun at the device's exact coordinates on that exact date. Move a thermostat from Chicago to Cleveland, both in the same time zone, and sunset shifts by roughly 20 minutes. Move it from Miami to Boston and the seasonal swing in day length more than doubles.

This turns a scheduling feature into a small astronomy problem embedded in a consumer product, and it is where a surprising number of otherwise good Shabbat timers and controllers get returned. A two-minute error in candle lighting is not a rounding nuisance to this customer; it is a product that cannot be trusted.

Compute It, Do Not Download It

The tempting shortcut is to fetch a table from a server. Resist it. A downloaded table goes stale, needs connectivity the product may not have, and commits you to operating an API endpoint for the ten-year service life of a device that sells for under a hundred dollars.

Computing solar position on-device is cheaper than it sounds. A standard solar position algorithm of the kind published by NOAA, or the Meeus formulation behind it, fits in one to two kilobytes of code and a few hundred bytes of working memory, and returns sunrise and sunset to within a few seconds. On a small microcontroller without a floating-point unit, expect a few milliseconds per evaluation using double precision, which is nothing for something you run twice a day. Budget it deliberately against the rest of your firmware using how much flash and RAM your microcontroller really needs.

The Inputs That Decide Accuracy

The algorithm is the easy part. Accuracy comes from the four things you feed it.

  • Coordinates. A tenth of a degree of longitude is about 24 seconds of time. A ZIP code centroid is usually good enough for a home product; a synagogue installation or anything published to a community should be set from a surveyed address or a GNSS fix. If you add a receiver, the selection tradeoffs are in GPS tracking device design.
  • Elevation and horizon. Standard sunset formulas use a mathematical horizon with a refraction allowance, typically a zenith angle of 90.833 degrees. Real elevation above the surrounding terrain pushes visible sunset later, by a minute or two at a few hundred feet. Decide explicitly whether your product uses sea-level times or elevation-adjusted times, then say so in the manual.
  • Time zone and daylight saving. Compute everything in UTC internally and convert only for display. Daylight saving rules are set by legislatures and do change, so either store a maintainable zone database or design the device to accept an offset update. This is one of the strongest arguments for shipping OTA firmware updates in a product like this.
  • The real-time clock. An ordinary 20 ppm crystal drifts roughly ten minutes a year. A 5 ppm temperature-compensated oscillator drifts closer to two and a half. Neither is acceptable unattended, so plan a sync source: network time, cellular time, GNSS, or at minimum a documented manual correction procedure with a drift warning after a set interval.

Opinions Are a Configuration Parameter

Sunrise and sunset are astronomy. Everything derived from them is halachic opinion, and different communities follow different ones. Dawn, nightfall, and the boundaries of the prayer hours are variously defined as a fixed number of minutes before or after sunset, as a proportional fraction of the day, or as the moment the sun reaches a specific depression angle below the horizon. Candle lighting is commonly sunset minus 18 minutes, but several communities use different margins.

Build this as data, not as code. A clean implementation stores each supported opinion as a small parameter set (method type, degrees or minutes, whether seasonal hours are measured from dawn or from sunrise) and exposes a single selection to the installer. Hard-coding one community's practice guarantees you cannot sell into the next city over. Always display which opinion is active, and never round to nearest: round conservatively in the safe direction, earlier for candle lighting and the start of a restriction, later for its end.

Where the Math Breaks

Above roughly 49 degrees north, in midsummer, the sun never descends to some of the depression angles these definitions use. Seattle, Minneapolis, Detroit, Toronto, and everything in Canada above them are real markets, and a product that returns an error, a garbage value, or silently falls back to midnight in those cities will be discovered on a Friday night.

Handle it deliberately. Detect the no-solution case, apply a documented fallback such as a proportional method, flag on the display that a fallback is active, and record the behavior in your certification submission. Test the boundary explicitly: midsummer at your highest supported latitude, both daylight saving transition days, and locations at the eastern and western edges of a wide time zone.

Validate Against Published Tables

The acceptance test for this feature is not a unit test you wrote from the same formula. Pick fifteen to twenty cities spanning your target latitudes, pull an authoritative published calendar for each, and compare every day of a full year for every time your product displays. A tolerance of one minute is achievable and is what a reviewer will expect. Keep the comparison as an automated regression suite, because the failures show up after a refactor of the time-zone handling, not on the day you write the algorithm.

Then get the algorithm and the opinion set reviewed by the same authority that reviews your control logic. Halachic reviewers examine the method, the parameters, and the rounding policy, and this is a normal part of the process described in halachic certification for products.

Why This Is Worth Building Well

A correct halachic time engine is a reusable asset. The same module drives lighting schedules, as in lighting control for Shabbat observance, sets the mode transitions in kosher smart home automation, and gates every appliance behavior that has to change at sunset. Companies that build it once, test it properly, and expose it across a product line ship faster than competitors who reimplement it badly in each device.

Get the Time Engine Right the First Time

Projects House builds and validates halachic time computation for embedded products: algorithm selection, opinion configuration, clock and sync architecture, high-latitude handling, and the year-long regression suite that proves it. Tell us your target markets and hardware platform through the contact form.