bhagolblog

Elsewhere · Kaveri Nambiar

The app's city menu

One field, three menus down, decides which sunrise your almanac asks about. Here is what it changes, how it goes wrong, and the two-minute check.

Two ways in. The gist assumes you have never met any of this before.

A printed page from an 1814 atlas, photographed in the bound book, the paper aged to a warm cream. The heading reads TABLE OF THE PRINCIPAL PLACES IN THE WORLD, with their Latitudes and Longitudes from London, and a small note underneath explains that towns in the United States are listed separately. Below it a ruled box holds three side-by-side panels of dense small type. Each panel has four columns headed Places, Countries, Latitude and Longitude, and the place names run in alphabetical order down every panel, each followed by figures in degrees and minutes.
Table of the Principal Places in the World, with their Latitudes and Longitudes from London, index page from A New Juvenile Atlas, John Melish, John Vallance and H. S. Tanner, Philadelphia, 1814. David Rumsey Map Collection via Wikimedia Commons, Public Domain

Every app that prints a panchang (pañcāṅga, पञ्चाङ्ग), the Indian almanac sheet for a single day, keeps a city in a settings field, and that city decides which morning your fast falls on. The field is usually three menus down. On some apps it sits behind a gear icon, then a line called Location, then a search box with a city already in it. On others you reach it by tapping the small grey place name at the top of the sheet, which most people read as a heading rather than as a button. Either way, a city is sitting in that box, and plenty of people are looking at it today for the first time since they installed the app.

Read what it says, then picture the address on your electricity bill. If the two are different cities, that box has been answering questions on your behalf.

Start with the fact the whole sheet leans on. Here a day begins at sunrise rather than at midnight. And sunrise arrives place by place: your street gets one moment, a town two hundred kilometres west of you gets a later one, and no two of them are working from the same instant.

The chain from there is short. A tithi (तिथि) is a lunar day, one step in the moon's separation from the sun, 30 steps to a lunar month. A tithi runs a little under a solar day, so it will not sit tidily inside one of our dates. It begins on one afternoon and ends the next evening. The sheet therefore needs a rule for deciding which date carries its name, and the rule is one minute long. Whichever tithi is running at sunrise gives the day its name. That is the udaya tithi (उदय तिथि), the risen tithi.

So the field picks a city, the city picks a sunrise, and the sunrise picks the name. That name is the date your app prints for ekādaśī (एकादशी), the eleventh lunar day that a great many households fast on. The same minute settles the day's nakṣatra (नक्षत्र), the moon's station among the stars, and the smaller figures printed beside it. The boxes down the margin, rāhu kāla (राहु काल) and the auspicious-hour lines, are slices of the daylight between that city's sunrise and its sunset, so they slide too. How to read a panchang takes the page apart column by column. Read it with this in mind and you will see how much of it stands on one search box.

One thing in there does not move. A tithi starts and finishes at two instants that belong to the solar system and not to any town. Change the city and all you have changed is the clock those instants are written on. That is the mechanism I worked through in your festival, eight thousand kilometres later: one moon, two evenings, two correct dates. Which of those dates reaches your phone is decided by that one field.

The wrong city that looks right

The obvious failure announces itself. If the box says Delhi and you live in Toronto, the sunrise line prints an hour you have never seen the sun come up at. You know in a second that something is off.

The quiet failure is the one worth an essay. Take a household in Dubai with the app still set to Delhi.

Delhi sits at about 77 degrees of longitude east. Dubai sits at about 55. The earth turns 15 degrees an hour, which is 4 minutes to the degree, so those 22 degrees are worth roughly 88 minutes. Everything the sun does in Delhi, it does in Dubai about an hour and a half later.

Now the clocks. Indian Standard Time runs an hour and a half ahead of Gulf time. Set 90 minutes of clock against 88 minutes of sun: the two very nearly cancel.

Watch what that does to the printed numbers. At the June solstice the sun rises in Delhi at about 5.22 by Indian clocks, and in Dubai at about 5.28 by Gulf clocks. At the December solstice Delhi gets about 7.08 and Dubai about 6.59. Each of these shifts by a minute or so from year to year, but the pattern holds: the two figures stay within about 10 minutes of each other all year, sometimes one ahead, sometimes the other.

So the household checks the sheet, sees a sunrise within 10 minutes of its own, and takes the app to be fine, even though it was computed for a city two thousand kilometres away.

The app is not fine. It is asking its one question at the wrong instant. Delhi's sun clears the horizon about an hour and a half before Dubai's, whatever the clock faces say, and the sheet is reading the sky at Delhi's moment.

How often does that change the answer? Thirty tithis fill a lunar month of about twenty-nine and a half days, so a tithi averages a little under 24 hours: near enough 23 hours and 37 minutes. A window of an hour and a half is about a sixteenth of that. So on roughly one morning in sixteen, the tithi running at Delhi's sunrise is not the one running at Dubai's. The two sheets then put different names on the same day.

Fifteen mornings out of sixteen, nothing at all. Then a morning when your phone says the fast is Tuesday and the sheet your temple uses says Wednesday, and nobody has blundered. Yours was computed for somewhere else.

The trap is open anywhere the clock difference between two cities happens to cancel the distance between them. Much of the Gulf sits in it. So does anyone whose app is set to a city in their own time zone but well to the east or west of them: New York against Detroit, Madrid against Warsaw.

How the wrong city gets there

Two ways, and neither of them is carelessness.

The first is that nobody ever set it. Type drikpanchang.com into a browser and, until you tell it otherwise, it computes for New Delhi, printing the latitude, the longitude, the elevation and the time zone it is using. A default has to be somewhere, and for that site's readership Delhi is a fair guess. It is simply not a statement about you.

The second is simpler: it was set correctly once, and then life moved on without it. The family moved from Edison to Fremont. The phone was replaced and restored from a backup made in another country. A cousin in Pune installed the app on a parent's phone during a visit and typed in the city he was standing in. Somebody entered their birth city into a box that was asking where they live now. None of these is a mistake at the moment it happens. Each one quietly becomes wrong later.

Two minutes, five questions

Find the field first. It hides under Settings, Location, Place, City or Change Location, and on many apps it is that grey line at the top of the sheet.

Then ask whether it holds a fixed city or your current position. Both are sensible. Only one of them changes when you get on a plane, and a fortnight in India with the app following you is a fortnight of Indian dates, which may be exactly what you want or exactly what you do not.

Third, find out which clock the times are printed in. Some sheets give everything in the local time of the chosen city, which is what the site above does, and says so on the page. When the city is wrong and the clock matches that wrong city, the two mistakes cancel out and look like everything is in order, exactly as they do in Dubai.

Fourth, check the sunrise against something outside the app. The US Naval Observatory's Astronomical Applications Department publishes free sunrise and sunset tables for any place on earth. They are given in local standard time, so add an hour yourself in the months your country keeps summer time. Two or three minutes of disagreement means nothing. Almanacs do not even agree among themselves: count from the sun's upper edge or from its middle, allow for your elevation or leave it out. Drik Panchang alone will give you four answers for one morning, about four minutes apart. An hour is not a difference of definition. An hour is a different city.

Fifth, take one date you actually care about, the next fast or the next festival, and compare the app against your temple's list and against home. If the three agree, you are done for the year. If they do not, you now know why, and you can choose.

That word is the point of all this. A temple fixes its festival on the evening its congregation can travel. A household keeps home's dates so that the phone calls land together. A family follows the sheet computed for the city it lives in. All three are keeping time properly, and none of them owes anybody an explanation. What is worth avoiding is the fourth case, where the date came out of a box nobody has opened since the app was installed.

One more field deserves a look while you are in there. If the app also draws charts, the birth details sit separately, and that place name is the town somebody was born in. It stays put when you move. People do sometimes correct it to their current city, thinking they are tidying up.

That is all of the screen work. The check I would do first is not on a screen at all.

Tomorrow, open nothing to begin with. Watch for the sun instead, and allow for whatever is in the way, because a roof or a hill hands it to you a few minutes late. Then read the sunrise line on your app. A few minutes between the two is the ordinary noise of buildings and definitions. An hour and a half is a city you do not live in.