You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for this library! It seems exactly what is needed in aantron/dream#270.
I tried round-tripping the three formats from the HTTP RFCs. For the RFC 850 format, with a two-digit year, the round-tripping doesn't quite work. The resulting date has the two-digit year. When printed in the preferred format,
Sat, 06 Nov 0094 08:49:37 GMT
Assuming these years refer to the 1900s (and since this format is obsolete), I had to write a function
letnormalize_yearptime=let ((year, month, day), time) =Ptime.to_date_time ptime inlet year =if year <100then year +1900else year inPtime.of_date_time ((year, month, day), time) |>Option.get
(* Option.get is safe here because this function updates the year. If the date was valid to begin with, it will be valid after the update. From @beajeanm: an additional consideration here is whether a two-digit year Y is a leap year if and only if Y + 1900 is a leap year, and we believe it is, as suggested by testing Ptime itself. *)
to normalize the year.
Should this be done in http-date? Is this something for the user or framework to decide? I can open a PR if appropriate.
The text was updated successfully, but these errors were encountered:
Thank you for this library! It seems exactly what is needed in aantron/dream#270.
I tried round-tripping the three formats from the HTTP RFCs. For the RFC 850 format, with a two-digit year, the round-tripping doesn't quite work. The resulting date has the two-digit year. When printed in the preferred format,
Assuming these years refer to the 1900s (and since this format is obsolete), I had to write a function
to normalize the year.
Should this be done in http-date? Is this something for the user or framework to decide? I can open a PR if appropriate.
The text was updated successfully, but these errors were encountered: