timestamp.parse_rfc3339 with implicit precision? | The Gleam Programming Language | Page 1

rugged leaf Feb 8, 2026, 4:11 PM

#

I want to parse time strings with implicit precision, so parse_datetime("2018") would be a valid timestamp with precision YYYY. How much rewriting of https://github.com/gleam-lang/time/blob/2b63bbc3795489ca8658dd0e0b7452c7eb214aeb/src/gleam/time/timestamp.gleam#L533 would I need to do to only go through the bytes once and get timestamp + precision? Or what approach in general would you take for this

import gleam/time/timestamp

pub type DateTimePrecision {
  YYYY
  YYYYMM
  YYYYMMDD
  YYYYMMDDThhmmsszzzz
}

pub type DateTime {
  DateTime(timestamp: timestamp.Timestamp, precision: DateTimePrecision)
}

pub fn parse_datetime (in: String) -> DateTime {
  todo
}

pub fn main() {
  echo timestamp.parse_rfc3339("2018")
  echo timestamp.parse_rfc3339("1973-06")
  echo timestamp.parse_rfc3339("1905-08-23")
  echo timestamp.parse_rfc3339("2015-02-07T13:28:17-05:00")
  echo timestamp.parse_rfc3339("2017-01-01T00:00:00.000Z")
}

GitHub

time/src/gleam/time/timestamp.gleam at 2b63bbc3795489ca8658dd0e0b74...

🕰️ Work with time in Gleam! Contribute to gleam-lang/time development by creating an account on GitHub.

#

just want to check that messing around with timestamp.parse_rfc3339 would be the best answer

sage shuttle Feb 8, 2026, 4:15 PM

#

You might get some mileage out of the gtempo library. That has a wider range of supported formats and can convert to gleam/time types.

#

Afaiu gleam/time is deliberately quite minimal

prime delta Feb 8, 2026, 4:28 PM

#

That would be against RFC3339

#

You would need to use some other specification, or specify your own syntax

#

Is there one in particular that you'd like to use?

#

If you do make this please do not call it parse_rfc3339. Having a function that is not RFC3339 but is called RFC3339 is going to confuse an already very complicated area.

#

ISO8601 miiight be what you want but it has a whole bunch of extra stuff in it, can be challenging to work with and there's not a singular good output for it

#

2026-02
2026
2026-02-08T14:30Z
2026-02T14:30+01
2026-W06-7T23:00
2026-039T12
2026-039

All valid ISO8601

#

It also has both 00:00 and 24:00 as two different times of day

rugged leaf Feb 8, 2026, 4:53 PM

#

The spec (fhir datetime) says a subset of ISO8601, with implicit precision and no 24:00. On avoiding confusion I believe this would not be a pub fn anyone would see; would just be used in decoder

prime delta Feb 8, 2026, 4:57 PM

#

There was a version of ISO8601 without 24:00, and they have have variable precision

#

Sounds like that one

#

Writing an ISO8601 parser sounds like it could be the way to go

#

I would avoid copying gtempo and instead copy gleam_time. gtempo's parsing code is slow and quite complex due to being regex based compared to gleam_time's pattern matching

rugged leaf Feb 8, 2026, 4:58 PM

#

Ah ok ty. Yeah copying gleam_time sounds good

prime delta Feb 8, 2026, 5:04 PM

#

Maybe I'll make an ISO8601 library...

rugged leaf Feb 8, 2026, 5:07 PM

#

I feel like I want a very particular parser, especially implicit precision, so idk if it would make sense as a specific case of a general parser. But your library would at least be interesting to see for sure

prime delta Feb 8, 2026, 5:09 PM

#

Can you share the spec with me? I can't find it 🙏 thanks

rugged leaf Feb 8, 2026, 5:10 PM

#

https://build.fhir.org/datatypes.html#dateTime is what I am going off of

prime delta Feb 8, 2026, 5:10 PM

#

YYYY, YYYY-MM, YYYY-MM-DD or YYYY-MM-DDThh:mm:ss+zz:zz
oh cool it's much simpler than ISO8601

rugged leaf Feb 8, 2026, 5:11 PM

#

Yeah I can probably just take gleam_time and not change anything too crazy

prime delta Feb 8, 2026, 5:11 PM

#

I can't see where it says what to do if (for example) the month or day is missing

rugged leaf Feb 8, 2026, 5:12 PM

#

Tbh idk, for now I’d be fine with failing

prime delta Feb 8, 2026, 5:12 PM

#

I mean if it's the valid format YYYY

rugged leaf Feb 8, 2026, 5:12 PM

#

Oh yyyy should succeed yeah

prime delta Feb 8, 2026, 5:12 PM

#

does that mean "the whole of that year" or "the very start of the year" or something else?

rugged leaf Feb 8, 2026, 5:13 PM

#

Ah I see, yeah idk probably up to the user to interpret

prime delta Feb 8, 2026, 5:13 PM

#

Surprised it doesn't say tbh

rugged leaf Feb 8, 2026, 5:15 PM

#

Well I think they want to leave room to implementers, iirc on money types one of the creators said something like “the less we say about this, the less we can get in trouble for”

Zulip

Public view of FHIR Community | Zulip team chat

Browse the publicly accessible channels in FHIR Community without logging in.

prime delta Feb 8, 2026, 5:18 PM

#

that's hilarious 😁

solemn ether Feb 8, 2026, 5:42 PM

#

prime delta Maybe I'll make an ISO8601 library...

🫡 …ISO8601 is wild iirc

prime delta Feb 8, 2026, 6:17 PM

#

truly

#

there's a reason gleam_time doesn't have it

solemn ether Feb 8, 2026, 6:19 PM

#

How important do you think an iso8601 parser is?

prime delta Feb 8, 2026, 6:20 PM

#

I think it could be useful at some point

solemn ether Feb 8, 2026, 6:20 PM

#

Parsers are fun to write at least so maybe important doesn’t matter

prime delta Feb 8, 2026, 6:20 PM

#

I'd give it a horrible API that preserves all the info about precision

sage shuttle Feb 8, 2026, 6:22 PM

#

Someone should recreate JS's new Date() in Gleam

prime delta Feb 8, 2026, 10:43 PM

#

OK well I nerd sniped myself

#

This consumed my evening 😅

#

https://hexdocs.pm/datetime_iso8601/index.html

#

pub type DateTime {
  CalendarDate(
    year: Int,
    month: calendar.Month,
    day: Int,
    time: option.Option(Time),
  )
  CalendarMonthDate(year: Int, month: calendar.Month)
  CalendarYearDate(year: Int)
  OrdinalDate(
    year: Int,
    day_of_year: Int,
    time: option.Option(Time),
  )
  WeekDate(
    year: Int,
    week: Int,
    day_of_week: DayOfWeek,
    time: option.Option(Time),
  )
  YearWeek(year: Int, week: Int)
}

pub type Time {
  TimeSecond(
    hour: Int,
    minute: Int,
    second: Int,
    nanosecond: option.Option(Int),
    timezone: option.Option(Timezone),
  )
  TimeMinute(
    hour: Int,
    minute: Int,
    nanosecond: option.Option(Int),
    timezone: option.Option(Timezone),
  )
  TimeHour(
    hour: Int,
    nanosecond: option.Option(Int),
    timezone: option.Option(Timezone),
  )
}

I hate it

mortal wedge Feb 8, 2026, 10:56 PM

#

all the web stuff is iso8601 so this is good to exist i think

prime delta Feb 8, 2026, 11:53 PM

#

it's not

#

it claims to be but it's all actually RFC3339

#

Which is the subset of ISO8601 that isn't bonkers

mortal wedge Feb 9, 2026, 12:21 AM

#

you sure 😂

solemn ether Feb 9, 2026, 2:26 AM

#

Whoa! That was fast 🤯

tardy igloo Feb 9, 2026, 7:05 AM

#

this is also very cool

prime delta Feb 9, 2026, 8:50 AM

#

mortal wedge you sure 😂

Yeah, check out that week stuff

#

And the reduced precision stuff

prime delta Feb 9, 2026, 8:50 AM

#

solemn ether Whoa! That was fast 🤯

I mostly copy pasted from gleam_time

#

I’m more of an AI skeptic but I’m trying to understand it since Gleam people do use it, so I asked a model to find missing test cases at points, and it did manage that!

#

I also tried to use it to make the data types but it made a horrible mess and I deleted that and started again.

#

Tbh I’m a bit conflicted on the whole thing, but if I don’t understand it I can’t do anything to stop the steady increase of low quality generative code. But I’m getting off topic

solemn ether Feb 9, 2026, 2:44 PM

#

prime delta I mostly copy pasted from gleam_time

Nice! I did recognize the style of it from gleam_time. It’s nice that that code was adaptable to this

#timestamp.parse_rfc3339 with implicit precision?