Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature]: A date and date-time field type

Open
  • Is something wrong?
#853 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
rust
Domain
database

Research direction

Read crates/data/src/value.rs for the existing field and value types, then review the format readers and writers named in the issue, including crates/data/src/filegdb.rs, source/fgb.rs, and source/postgis.rs. The proposal leaves key design questions unresolved and spans multiple formats, editing, queries, projects, and the time slider. Work can start once maintainers agree on the date model and scope; done means date values round trip with the intended schema and work in the agreed consumers.

Written by the indexing model from the issue text.

Description

enhancement
What problem does this solve?

FieldType has Integer, Double, Text and Boolean (crates/data/src/value.rs), so every date RustGIS reads becomes text:

  • Shapefile D fields are read as YYYY-MM-DD text and written back as Character fields.
  • File Geodatabase date, date-only, time-only and date-time-offset fields come in as text (crates/data/src/filegdb.rs:284).
  • FlatGeobuf DateTime columns (source/fgb.rs:525), PostGIS timestamps (source/postgis.rs) and spreadsheet dates (sheets.rs, as ISO text) arrive as text as well.
  • edit.addField has no date type.

Dates are central to everyday work: permit, application, hearing and expiry dates; inspection logs; crash and count records. As text they sort only when ISO-formatted, can't be compared in a where clause (issued >= '2026-01-01' compares strings), and break in Calculate Field (issued + 30 gives 2026-06-0330). A round trip through Shapefile or GeoPackage also changes the schema, so a county system that expects a date column gets a text one back.

Several roadmap items already assume dates exist: date formats in pop-up templates, date controls in quick filters, and the time slider. The time slider currently guesses which fields hold dates by sampling 500 values and accepting a field when 60% of them parse (crates/map/src/time.rs).

Proposed solution

This changes the data model, so I'm asking how you'd like it shaped before anyone builds it. A starting point:

  • The type. Add FieldType::Date (a calendar day) and FieldType::DateTime (an instant, stored as UTC with any offset applied), and matching Value variants. Use one plain integer representation, so nothing depends on std::time and the wasm build is unaffected.
  • Read and write it in each format:
    • Shapefile D;
    • GeoPackage DATE/DATETIME;
    • FileGDB date kinds;
    • GeoParquet/Arrow date32/timestamp;
    • FlatGeobuf DateTime;
    • CSV and spreadsheets: detected like the time slider does today, or chosen when adding the file.
    • GeoJSON stays text on write, as ISO 8601.
  • Where it shows up:
    • edit.addField gains date and datetime.
    • The table shows dates in the user's format and edits them with a date picker.
    • Where clauses compare dates.
    • The time slider uses date fields directly and keeps its guessing for text.
    • Calculate Field date arithmetic waits for the expression engine.
  • Projects: .rgis files gain the new values. Older projects keep their text fields; a "convert field to date" command could follow.

Questions for a maintainer:

  1. One type with an optional time, or two types?
  2. Should time-only fields (FileGDB has them) stay text?
  3. Should this land before the expression engine, or as part of it?

I'm glad to help build it once the shape is agreed.

Estimated scope

Wishlist: a larger or longer-term idea

Alternatives considered
  • Keep dates as ISO text and teach each consumer to parse it. This is what the time slider does today. It works for display and the slider, but leaves the schema round trip and comparisons wrong, and every consumer repeats the guessing.
Dominant language
Rust
Stars
1.9k
Forks
268
Avg merge
3h 8m
Merged PRs (30d)
688

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from opengeos/RustGIS

All issues in opengeos/RustGIS

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.