Updated · Build 1
Ideas for what loc.is could become.
Explorations are not committed features. They will come and go, will break, may not work yet, and will probably change often. A working demo is not a supported interface. Agents should read the agent how-to guide before relying on anything here.
These are proposals and experiments, not commitments to ship. Some candidate syntax already has a prototype, but its public meaning and supported behavior are still being evaluated. The how-to guide covers the main ways to use loc.is today.
Inspect the current experimental Earth-rectangle format: its alphabet, axis choices, decoded geometry and short/long representations. The format is still being evaluated; it is not a finalized web standard or a frozen URL contract.
A shortcode describes a series of parent and child rectangles on Earth. The first tier selects an area of the Earth; each following tier selects a smaller sub-area inside the preceding rectangle. Each child stays within its parent and is smaller than it. The complete code identifies the final rectangle, while its earlier tiers describe the enclosing areas.
Read each tier as a pair of axis choices: longitude (X), then latitude (Y). An axis choice is a base symbol, optionally followed by a Y or Z modifier. For example, 6Z8Z is one tier with two choices—6Z for longitude and 8Z for latitude—not two tiers made from pairs of plain characters.
Example: 68 → 683YM. Groups and modifiers change the selection within a tier.
Codes use the alphabet from Douglas Crockford’s Base32, ignoring case. O is accepted as 0; I and L are accepted as 1. LOCIS assigns these symbols to geographic divisions, groups and modifiers; its location format is not a conventional Base32 encoding of a number.
The full digit-and-letter sequence is shown below. Pink, crossed-out tiles mark I, L, O and U, which are absent from the Crockford Base32 alphabet used for LOCIS codes.
0123456789ABCDEFGHJKMNPQRSTVWXYZ
A location code needs to work away from a keyboard: handwritten on a note, copied from a flyer, read aloud or typed from a photograph. We use one uppercase spelling, with no distinction between upper and lower case when reading it. A reader does not have to preserve the case of each letter to reach the same area.
Crockford’s alphabet removes I, L and O, which can be confused with 1 and 0, and also leaves out U. In LOCIS, leaving out U avoids confusion between handwritten U and V. Accepted input aliases make a handwritten O read as 0 and I or L read as 1. These choices reduce transcription mistakes; they do not make every handwriting style unambiguous.
Base32 is enough for the choices we need: 24 fine divisions, six groups and two modifiers. Earlier LOCIS algorithms used Base64, but their finer subdivision shrank the Earth’s areas too quickly for the useful intermediate scales we wanted. The current design favors manageable refinement and easy transcription over maximum information per character. Alphabet size and subdivision rate are separate choices: using Base64 would not inherently require a 64-way grid.
Another reason for choosing the Base32 alphabet is URL routing. Canonical location codes use uppercase letters and digits, leaving lowercase-starting paths available for site, developer and semantic routes. This includes names of any length and later capitalization, such as /assets/ or /aRoute/. The /s/ asset namespace is already in use; reserving all lowercase-starting routes is the intended routing contract and still needs implementation. This separation is a LOCIS routing choice, not an automatic property of Base32, and code input in search can still ignore case.
The root has 24 longitude bands around the Earth. Each covers 15°, or roughly one hour of solar time. Latitude starts with 12 bands so the first cells span 15° on both axes; subsequent fine steps divide each parent axis into 24. This gives us a useful geographic scale progression while keeping the root longitude bands close to the familiar idea of hourly time zones.
That resemblance is deliberate, but the bands are not official time zones. Civil zones follow borders and policy, and can have fractional-hour offsets or daylight saving. See location time and fast comparisons for solar estimates and civil-zone applications.
The 32-symbol alphabet has three jobs: 24 symbols pick individual divisions, six pick groups of four, and the remaining two modify a choice. Here “primes” means the Y and Z modifiers; it does not mean prime numbers.
0123456789ABCDEFGHJKMNPQEach symbol chooses one of the 24 small divisions along an axis.
R S T V W XR selects 0–3, S selects 4–7, T selects 8–11, V selects 12–15, W selects 16–19, and X selects 20–23.
Y ZY includes one more adjacent choice of the same size. Z includes two more. They follow a division or group symbol.
1Y covers divisions 1–2; 1Z covers 1–3. RY covers 0–7; RZ covers 0–11. Every selection must remain inside its parent.The first grid has 24 longitude bands, counted eastward from 180° west, and 12 latitude bands, counted northward from 90° south. Each fine cell spans 15° on both axes. Each later fine-cell pair divides its parent into 24 × 24 cells: the next fine cell spans 0.625° on each axis. Equal angles cover different ground distances at different latitudes.
0–Q select one fine division. R, S, T, V, W and X select successive groups of four. Y extends the preceding choice by one neighbor of the same size; Z extends it by two. For example, 1Z selects divisions 1–3, and RZ selects divisions 0–11. A span must stay inside its parent, so the first latitude choice must fit within 12 divisions.
In a normal route, all pairs before the last choose single fine divisions. The final pair may use groups and Y/Z modifiers to widen its spans. The first latitude choice must end within band 12: 0–B are its fine choices; C–Q are available only on later latitude steps. Y and Z are modifiers, not standalone choices. A route supports up to eight X/Y pairs.
Each group contains four neighboring cells. The six group labels below cover the same 24 divisions, from left to right.
Blue cells show R: the first four divisions, 0–3. Groups select a wider part of the same tier; they do not create another tier.
A single cell at the next tier is 1/24 of this parent’s width along the axis.
The same 24 cells, six groups and Y/Z choices repeat at this smaller scale.
1 · one cell
1Y · two adjacent cells
1Z · three adjacent cells
R · four cells
RY · two adjacent groups: eight cells
RZ · three adjacent groups: twelve cells
| Final selection tier | Cell + Y | Cell + Z | Group + Y | Group + Z |
|---|---|---|---|---|
| Tier 1 · Earth | 1Y0 | 1Z0 | RY0 | RZ0 |
| Tier 2 · inside 68 | 681Y0 | 681Z0 | 68RY0 | 68RZ0 |
| Tier 3 · inside 6810 | 68101Y0 | 68101Z0 | 6810RY0 | 6810RZ0 |
0. Earlier tiers use single cells. Y means one additional choice of the same size; Z means two. The rule repeats at every supported tier, up to eight X/Y pairs. A primed final choice cannot be used as an intermediate parent in a normal route.68 selects longitude band 6 and latitude band 8: 90°–75° west and 30°–45° north. To refine it, add a second X/Y pair.
In 683YM, that pair is 3Y then M. X selects two adjacent fine divisions, 3 and 4; Y selects fine division 20. The resulting rectangle is 88.125°–86.875° west and 42.5°–43.125° north. Its width is 1.25° and its height is 0.625°.
Adding a new tier selects a smaller rectangle within the previous one. Adding Y or Z to a choice changes the selection within that same tier: it includes neighboring subdivisions, but the resulting child remains smaller than its parent. Extra characters can therefore widen a selection at an existing tier; they do not always add another tier.
Each axis span also has a two-digit hexadecimal value. The long route uses X byte, then Y byte. 683YM and h/06081B14 open the same rectangle. A long-code link temporarily redirects to its short form.
For datasets, caches and database indexes, shortcodes and longcodes can be stored without http:// or https:// and without the domain. For example, store the shortcode 683M or the longcode 06080314 as a text value, with its encoding type and relevant version/source context. Preserve leading zeros.
Public presentation must always include the web protocol and domain. When publishing to the web or encoding a 2D barcode, including a QR code, use the complete URL: https://loc.is/683M or https://loc.is/h/06080314. Restore the longcode’s /h/ route when exporting it. Internal storage conventions do not change this public-link requirement.
Hex values 00–53 describe the 84 span choices for a 24-division axis. The 12-band latitude root permits only the choices that fit. For this example, 6 → 06, 8 → 08, 3Y → 1B and M → 14, giving 06081B14. The long code stores each complete span directly; it has no Y/Z modifiers. Leading zeros are part of the code.
Search also accepts Plus Codes as an alternate location format. A shortened Plus Code needs a reference place, such as CWC8+R9 Mountain View, California. Full codes can be linked with /?pluscode=849VCWC8%2BR9.
Change X and Y to see the rectangle and its code update. Start with a single cell, add neighbors, or try a wide span.
Earth · 24 longitude × 12 latitude divisions
68Long code0608In the full lab, load a code of your own, compare rectangles, or share a link to your selection. It also includes experiments with features still under consideration.
The code carries the place itself, rather than pointing to a randomly assigned record. That makes it a compact, shareable location link that can also be used as location metadata.
Shortcodes describe areas, not street addresses, identities or verified presence. More fine-cell pairs narrow the rectangle. Y/Z modifiers widen the final span, so character count alone does not tell you its size. A smaller rectangle is not proof that a location measurement was more accurate. Degrees cover different ground distances at different latitudes, and decoding uses the rectangle’s center for the map.
Named-place search uses a revisioned local cache when available. Provider centers and boxes are snapshots that may disagree or change. Curated regions can exclude remote water territory or use an explicit urban scope; Tahoe retains its lake. The existing terminal-rectangle fitter selects an approximate code without sub-rect refinements. The place atlas shows coverage and extra area, rather than implying an exact boundary. Dark dashed red marks provider bounds, brighter dashed red the generated region, and purple its generated bounding box. Cyan remains the encoded rectangle. Uncached places use provider bounds or a place-type estimate.
The boundary atlas lets you inspect the source box, encoded box, short code, long code, and measured fit together. Source extents can include lakes, islands and distant territories.
Open questions include equivalent-rectangle identity, extension namespaces, metadata conventions and interoperability. The sections below discuss those proposals alongside the current experimental format.
A set could share several separate places in one link: stops on a walk, a few meeting options, or places that belong to the same story. A bounding box could describe the enclosing area between two locations.
Candidate set: 68,78
Candidate enclosing box: 68..78The comma would select the member rectangles; two dots would select the area enclosing the two endpoint rectangles. We still need to settle member ordering, duplicates, long-code equivalents and date-line behavior before treating these as a stable feature.
In the current prototype, plain 12,34 is GPS latitude and longitude; code:12,34 disambiguates a numeric code set. Prototype limits, such as 64 set members, may change. A set does not inherently have one center or one Location Time.
A single period is being explored as a relative subdivision: RR.00 would select a small cell inside the rectangle described by RR. This is different from the two-dot enclosing box. The full lab and decoder can explore dotted paths, but sub-rectangle generation is reserved for further evaluation.
Better fitting also needs a clearer treatment of wide regions, the date line, poles, and disconnected regions. Letting X and Y finish at different depths—or leaving one axis unchanged while refining the other—could improve the fit of long, narrow areas. No whole-axis symbol or new byte has been assigned.
A small location preview could sit inside another website, expand from a link, or accompany an event. We’re considering dedicated embeds, hovercards and JavaScript widgets.
Like an embedded X or Bluesky post, a proposed location embed could appear inline with the publisher’s story. Readers see the place in context and can open the full map. Here is a sample webpage layout:
We’re meeting in the park on Saturday at two. Bring a blanket and something to share. The location card below shows the meeting area to check before setting out.
Look for the yellow balloons when you arrive. If you’re bringing friends, send them the location link with the invitation.
An iframe can be used to experiment with loading the full page, but it is not a supported embed contract. It may include the full map and privacy choices rather than a compact preview.
<iframe
src="https://loc.is/4B1D73D51FCC"
title="Meeting location on loc.is"
width="600" height="700"
class="locis-embed-frame"
loading="lazy">
</iframe>A supported embed would need defined sizing, accessibility, privacy, resource loading and referrer behavior. A location URL currently returns HTML; an image preview or script widget would need its own resource.
This prototype is for evaluating ideas. Attributes such as data-locis-name, data-locis-tags, data-locis-summary and data-locis are not committed public interfaces. Their names and behavior may change.
Hover over London or Paris below, or use Tab to focus either place. A small card shows a map and information about the location, optimized for the article, and the tags used for its focus. Press Esc to dismiss it.
A walk through London or Paris offers a new perspective on architecture and public space.
London uses an ordinary loc.is link. Paris uses the full location URL in a data-locis attribute on a text element. Both inherit the article’s focus tags:
<script type="module" src="/widgets/locis-hovercard.mjs"></script>
<article data-locis-tags="architecture, public space, walking">
A walk through
<a href="https://loc.is/B9QA" data-locis-name="London">London</a>
or
<span data-locis="https://loc.is/C936VZ3Z"
data-locis-name="Paris" tabindex="0">Paris</span>
offers a new perspective on architecture and public space.
</article>Save the prototype script and its map assets in your site’s /widgets/ folder, then add the example HTML. The map assets are hovercard-map.html, hovercard-map.mjs, shortcode.mjs, axis-spans.mjs, blue-map.json and the built vendor/ MapLibre files. Use data-locis-tags on an individual location to override the article’s tags, or data-locis-summary to supply a short description.
This is a prototype: the publisher supplies the name, tags and optional description. The map decodes the supplied location code and loads map tiles from OpenFreeMap when the card opens. It does not geocode place names or analyze the article. Dedicated embeds, automatic metadata reading and a live information service remain features under consideration.
We plan to provide APIs and SDKs that help developers geocode places and addresses on their own servers, or in a web page when a user loads it. These tools are not available yet.
For now, geocode on the loc.is website: search for the location, check its area on the map, then copy and paste its URL into your website or content. The hovercard prototype displays an existing location reference; it does not perform the geocoding step.
See the current developer workflow for copy-and-paste examples.
A location link could travel with a photo, describe where an event happens, or give a page a geographic context. The examples below are candidate conventions for other tools. LOCIS does not yet read or act on them.
<img src="photo.jpg"
alt="Our favorite place to watch the sunset"
data-locis="https://loc.is/4B1D73D51FCC">The custom data-locis attribute tags the HTML element. It does not change the image file or automatically load a map. A normal clickable image link is already covered in the guide.
An experiment could store a readable URL in EXIF’s existing UserComment field. With ExifTool, the write and read-back commands are:
exiftool -EXIF:UserComment="Location: https://loc.is/4B1D73D51FCC" photo.jpg
exiftool -s -EXIF:UserComment photo.jpgThis replaces an existing UserComment and normally leaves a photo.jpg_original backup. It is a text link in an existing field, not a standardized LOCIS field. Standard GPS tags still hold coordinates. Metadata may be stripped when sharing, and retained location data reveals the tagged place.
A loc.is URL can be used as an ordinary link inside existing microformats2 markup. No LOCIS-specific class or attribute is required for the examples below. h-event describes the event, and its p-location can contain a nested h-card for a named place.
Starts .
Bring a blanket and something to share.
Fictional event and meeting-area assignment, not a verified picnic or bench.
<div class="h-event">
<h2 class="p-name">A picnic with friends</h2>
<p>Starts <time class="dt-start"
datetime="2027-06-12T14:00:00-07:00">12 June 2027, 2 pm</time>.</p>
<div class="p-location h-card">
<a class="p-name u-url"
href="https://loc.is/38MC0AC8H65G">
Our meeting spot in Golden Gate Park
</a>
</div>
<p class="p-summary">Bring a blanket and something to share.</p>
</div>A microformats2 reader can extract the event name, start time and summary, plus a nested location with its name and URL. The location’s u-url is the loc.is link; it is not the event’s permalink. If the event has its own page, put its u-url on the event separately. Readers need no knowledge of the shortcode to preserve or open the place link.
h-geo supplies decimal latitude and longitude. A publisher can add it inside the place’s h-card, alongside the URL. Here the coordinates are the sample rectangle’s decoded center, rounded to six decimal places; they are a representative point, not a surveyed bench or the area’s boundaries.
<div class="p-location h-card">
<a class="p-name u-url" href="https://loc.is/38MC0AC8H65G">
Our meeting spot in Golden Gate Park
</a>
<span class="p-geo h-geo">
<data class="p-latitude" value="37.769400">37.769400</data>,
<data class="p-longitude" value="-122.486200">-122.486200</data>
</span>
</div>A generic reader can use the point; a future LOCIS-aware reader could also decode the URL to recover the rectangle. Keep those meanings separate: h-geo describes a point and does not express LOCIS bounds, a set of areas or measurement accuracy.
u-url · https://loc.is/…Microformats reader
Reads the event and its named place URL.
Future LOCIS-aware reader
Could decode that URL into geographic bounds.
The event URL identifies the invitation. The location URL identifies an area.
The first extension could be URL recognition: retain standard event/place fields, then let an interested reader decode a loc.is URL for an area preview or geographic comparison. This is an application of existing markup, not a new microformat. Automatic discovery, decoding and indexing by LOCIS are not implemented or promised here.
Additional area, provenance or indoor semantics would need documented meanings, examples and interoperability testing. Prefer existing properties where they fit; discuss new vocabulary through the microformats community rather than presenting an invented LOCIS property as a standard. Preserve the readable place name and full HTTPS link so the page remains useful to readers that do not implement an extension.
<meta name="locis:location"
content="https://loc.is/4B1D73D51FCC">This would be a custom convention, not a standard search-engine field. A reader would need to distinguish a claimed location from verified evidence about it.
Keep your writing, event details and replies on your own website, and use a loc.is link for the geographic area. These examples use ordinary HTTPS links and existing IndieWeb markup; they do not require a LOCIS account or a new LOCIS publishing API. The IndieWeb location guide describes location information in notes, photos and events.
Found a quiet spot to read after our walk. Here’s the area for next time.
Fictional journal entry and spot assignment. Share only the location detail you intend to publish.
<article class="h-entry">
<a class="u-url" href="https://example.org/journal/park-walk">
Permalink to my walk
</a>
<h2 class="p-name">An afternoon in the park</h2>
<div class="e-content">
<p>Found a quiet spot to read after our walk.</p>
</div>
<div class="p-location h-card">
<a class="p-name u-url" href="https://loc.is/38MC0AC8H65G">
Golden Gate Park reading spot
</a>
</div>
</article>Replace the example.org permalink with your own post URL. Your post remains the story’s address; the nested place link identifies its area. The same pattern can accompany a photo or travel note. A location link describes a place, not proof that its author was there.
Publish the picnic h-event example on your event page. Keep its date, meeting instructions and updates there, with the checked loc.is link for the meeting area. Share the event-page URL so visitors get the invitation as well as the map. Friends can link back to that event from their own sites.
The IndieWeb RSVP pattern uses an h-entry reply and a p-rsvp value. The reply target is the organiser’s event page. The loc.is URL remains a separate map link:
<article class="h-entry">
<p class="p-summary">
<a class="p-author h-card" href="https://example.net/">Alex</a>:
<data class="p-rsvp" value="yes">I’ll be there!</data>
Replying to <a class="u-in-reply-to"
href="https://example.org/events/park-picnic">the park picnic</a>.
</p>
<p>Meeting area: <a href="https://loc.is/38MC0AC8H65G">
open the map</a>.</p>
</article>These example domains stand for the attendee’s and organiser’s websites. If their software supports Webmention, the attendee’s site can notify the organiser’s event page about the published reply. Notification, verification and RSVP display belong to those sites. LOCIS does not provide a Webmention receiver, RSVP service or attendance tracking here.
Keep the full loc.is URL in the post body or shared text, with a readable place name. An HTML feed item can retain the link; a plain-text copy can show Meeting area: https://loc.is/38MC0AC8H65G. Readers can open the map even when a feed reader or another platform omits microformats or embeds. Formatting and metadata retention depend on the publishing tool.
A future IndieWeb reader could recognize these location URLs and offer area previews or geographic grouping. The examples above publish links today; automatic LOCIS discovery, reader previews and cross-site geographic indexing remain ideas under consideration.
Decoding a loc.is link gives numeric bounds. A future application could use those bounds for local calculations: testing whether a point is inside an area, checking which rectangles overlap, or comparing their centers before doing a more detailed search. These checks do not need a place-name lookup. Geometry still needs to handle areas crossing the date line.
A future query could find posts, pages or events whose locations overlap a region. Geographic containment needs decoded geometry: a text-prefix search alone misses places described through overlapping spans or equivalent paths.
We’re also considering a preferred short and long spelling for each rectangle. Different dotted paths can currently describe identical geometry. A deterministic fitter does not solve that identity problem. Any normalization would need to preserve the exact rectangle and existing shared links.
A database can use a location’s hierarchical code as a text key. Taking a leading substring gives a coarser bucket; searching that prefix finds records with the same stored ancestry. This is a geohash-like indexing technique, not the standard Geohash encoding or a committed LOCIS database integration.
68 → 683M0608 → 06080314The index keys below omit the protocol and domain for internal storage. Follow the public URL requirement when publishing or putting them in a barcode.
These examples assume validated uppercase fine-cell-only keys, with no groups, modifiers, dots or compound expressions. Store one key per location record, together with its original URL, encoding version and decoded geometry. For point data, choose a consistent precision. If you index an area’s center as a point, label that choice: its key does not represent the whole area.
-- Application-validated fine-cell keys, stored as text.
CREATE INDEX places_short_prefix
ON places (short_key text_pattern_ops);
CREATE INDEX places_long_prefix
ON places (long_key text_pattern_ops);
-- Same first-tier bucket in either spelling:
SELECT id, location_url FROM places
WHERE short_key LIKE '68%';
SELECT id, location_url FROM places
WHERE long_key LIKE '0608%';
-- Substrings are useful for counts by coarse bucket:
SELECT substring(short_key FROM 1 FOR 2) AS bucket,
count(*) AS records
FROM places
GROUP BY bucket;PostgreSQL can use appropriate B-tree indexes for anchored prefix patterns; text_pattern_ops supports pattern matching independently of locale ordering. Applying substring to every row is a different query shape: do not assume the ordinary column index will accelerate it. For frequent fixed-depth grouping, consider a stored bucket or matching expression index and inspect the query plan. See operator classes and prefix pattern indexes. Other SQL engines have different syntax and collation rules.
db.places.createIndex({ short_key: 1 });
db.places.createIndex({ long_key: 1 });
db.places.find({ short_key: { $regex: "^68" } });
db.places.find({ long_key: { $regex: "^0608" } });
// Bucket counts: keys are validated ASCII text.
db.places.aggregate([
{ $group: {
_id: { $substrBytes: ["$short_key", 0, 2] },
records: { $sum: 1 }
} }
]);A case-sensitive anchored MongoDB prefix regex can use a suitable index. Normalize at ingestion rather than adding a case-insensitive flag. The aggregation $substrBytes example computes buckets; it is not an indexed prefix lookup. For frequent bucket queries, persist the validated prefix in its own indexed field. Bind query values and escape pattern metacharacters when building searches from user input.
Real LOCIS routes can contain Y/Z modifiers, four-division groups, dotted paths, sets and enclosing boxes. In shortcodes, a tier can take more than two characters; parse complete X/Y choices before extracting an ancestor. In longcodes, each axis span occupies two hexadecimal characters, but separators and alternate paths still matter. An arbitrary substring from the middle has no ancestor meaning.
For example, 68Z begins with 68, but its latitude selection includes neighboring bands outside the rectangle selected by 68. Conversely, an overlapping grouped area may have a different prefix. Equivalent rectangles can also have different spellings. A prefix search on arbitrary original codes therefore does not prove containment and can miss overlaps.
For complete area queries, decode the geometry and use a spatial index, or generate a documented covering set of fine-cell keys and then check the original bounds. A query crossing bucket boundaries needs every intersecting bucket. Preserve date-line handling and the original area; do not silently replace it with its center. These are application design options requiring validation and benchmarks, not shipped SQL/MongoDB adapters.
Location Time currently uses the civil time zone at a rectangle’s center. The comparisons and display extensions below are explorations, not committed APIs or performance benchmarks.
For a large list of locations, an application could decode each area once and compare its center longitude with the user’s. Longitude gives an inexpensive estimate of how far apart their solar days are: 15° is about one hour, or 1° about four minutes. This could group places whose sun is at a similar stage of the day without a timezone lookup for every comparison.
Approximate solar offset in minutes = longitude × 4
User: 30° east → +120 minutes
Location A: 45° east → +180 minutes → 1 hour ahead
Location B: 15° east → +60 minutes → 1 hour behind
Location C: 90° west → −360 minutes → 8 hours behindFor bulk “timezone-feel” sorting, compare these solar offsets as a 24-hour circle: 179° east and 179° west are about eight solar minutes apart, rather than almost a day apart. Use the complete decoded area’s center, including groups and modifiers, rather than assuming its first character is a timezone number.
“Daylight feel” here means a similar solar-time phase, not a prediction of daylight hours or sunrise. Latitude and season affect how long the day lasts; solar-position calculations are needed for a more detailed model. For matching actual local clock times, use the UTC-offset comparison below. These are possible applications of the geometry, not committed sorting APIs or measured speed claims.
360° ÷ 24 = 15° per band
longitude × 4
Approximate solar offset in minutes.
Decode each area once, then compare its center. Use circular differences across the date line.
Official clock time still needs civil-zone rules. Day length also needs latitude and season.
For a list of offices, events or collaborators, an application could rank locations by how close their UTC offset is to the current user’s. Once the offsets are resolved, the comparison is simple arithmetic, using minutes to include half-hour and quarter-hour offsets:
time difference = abs(location offset − user offset)
User: UTC+02:00
Location A: UTC+01:00 → 60 minutes apart
Location B: UTC+03:00 → 60 minutes apart
Location C: UTC−05:00 → 420 minutes apartA and B tie for the closest offset. The application could break the tie using geographic distance or another preference. A similar local time does not mean a location is physically nearby.
Compare every offset at the same instant: now for a current-time search, or the intended meeting date for planning. Resolve each location’s civil time zone using geographic boundary data, then apply the IANA Time Zone Database rules for its UTC offset and daylight saving. A shortcode does not encode a civil time zone, and longitude alone cannot determine it. For an area spanning zones, the application must choose a representative point or consider all intersecting zones.
With resolved zones and offsets cached for the relevant instant, ranking the list only needs subtraction and comparison. This is a possible application of decoded locations, not a committed LOCIS query or API.
A future view could list other time zones that overlap a large rectangle, making the ambiguity visible.
We’re also considering event-time conventions that retain the event date when a local schedule uses hours beyond 24. Those displays would need clear rules around midnight, locale and daylight-saving transitions.
This example explores conference navigation. A supported indoor interface for floors, halls and booths has not been committed. Ordinary location URLs can show geographic areas today; the organiser must supply the floor plan and indoor directions separately.
For an exposition centre, put the arrival link in the invitation and QR code on the badge. In the programme, link each hall or meeting area beside its session details. Keep “Ground floor”, the hall name and booth number in the programme and on your floor plan.
Open all four exhibition areas on one map. In a real programme, keep the numbered legend beside the link so visitors can match the areas to your floor plan.
loc.is describes areas on Earth; it does not encode a floor, booth number or indoor route. Rooms stacked above one another may share the same geographic area. Use the venue’s floor plan, signs and accessibility information for the final indoor directions.
We’re actively looking for feedback on how to specify vertical height (a Z axis) and interior spaces. How should a location link distinguish places above one another, or identify a room within a building? This is an open exploration: no height or indoor-space syntax is committed, and experiments may change, break or disappear.
A link might include context such as ?floor=2&room=201. These are proposed labels, not an implemented room resolver. A label does not define a building’s shape, a floor’s height or a room’s boundaries.
The location rectangle should remain a durable geographic reference even if a building changes name or a room is renumbered. Resolving indoor locations would require an explicit data model and sources for the indoor geometry.
Other encodings, height and volume, and locations beyond Earth are under consideration. Possible alternate-format entry points such as /g/ and /e/ have no settled payload grammar.
Earlier ideas such as mars*CODE illustrate a possible body or coordinate-system scope; they are not supported location links. Any spatial extension needs defined units, origin, axes, reference frame and valid ranges. Alphabet expansion and versioned namespaces also remain design questions.
With a specific contribution choice, device fixes might help compare IP-based location estimates over time. The model would need to account for shared networks, VPNs, mobile connections, changing addresses and deliberately misleading submissions.
Allowing the browser to show your location would not automatically authorize contributing it. Resolution, retention, publication thresholds and abuse controls would need to be defined before collecting observations for this purpose.
Experimental storage or caching is another possibility, not an installed feature. Any new purpose would need its own explanation and an appropriate choice about what is kept and for how long.