~torresjrjr

Europe/London

https://torresjrjr.com/

Trackers

~torresjrjr/lateximgbot

Last active 10 months ago

~torresjrjr/Bezier.py

Last active 10 months ago

~torresjrjr/go-nestedtext

Last active 1 year, 2 months ago

~torresjrjr/fetch

Last active 1 year, 2 months ago

~torresjrjr/birck.vim

Last active 1 year, 2 months ago

~torresjrjr/pdssg

Last active 1 year, 2 months ago

~torresjrjr/gemini.vim

Last active 1 year, 2 months ago

~torresjrjr/linkchanbot

Last active 1 year, 3 months ago

~torresjrjr/dotfiles

Last active 1 year, 4 months ago

#647 datetime: complete timezone formatting and parsing 8 days ago

Comment by ~torresjrjr on ~sircmpwn/hare

Remaining TODOs:

  • Parsing of %Z
  • Parsing of %L

#647 datetime: complete timezone formatting and parsing 9 days ago

Comment by ~torresjrjr on ~sircmpwn/hare

Haelwenn (lanodan) Monnier referenced this ticket in commit 65449dd.

#647 datetime: complete timezone formatting and parsing 9 days ago

Comment by ~torresjrjr on ~sircmpwn/hare

Haelwenn (lanodan) Monnier referenced this ticket in commit 65449dd.

#647 datetime: complete timezone formatting and parsing 9 days ago

Comment by ~torresjrjr on ~sircmpwn/hare

Update: The %L format specifier for the locality/timezone name was introduced for formatting (but not parsing) in commit 6741ce10.

#720 time::chrono: handle absent UTC leap seconds data a month ago

Comment by ~torresjrjr on ~sircmpwn/hare

Solution 1: The user should have to explicitly call an exported function (chrono::init_utc_leapsecs()) to load leapsec data to later use chrono::utc. Any error is handled at call time.

Solution 2: There should be a fallback to some leapsec data. Potentially dangerous.

Solution 3: There should be a fallback to just a constant. Potentially dangerous.

Faking UTC conversions (solutions 2 & 3) kinda defeats the purpose of the UTC timescale existing and would make bugs and debugging hell, not to mention the inconsistency between systems' installed versions of the stdlib and leapsec data. I prefer solution 1.

#720 time::chrono: handle absent UTC leap seconds data a month ago

Ticket created by ~torresjrjr on ~sircmpwn/hare

If no UTC leap seconds data is available from the system, the @init responsibile for filling up the utc_leapsecs array fails silently, causing crashes when using the incomplete utc timescale converters (see #642). How should we handle this case?

#618 time::chrono: MTC gives wrong time a month ago

Comment by ~torresjrjr on ~sircmpwn/hare

The current MSD (Martian Sol Date) is currently approximately 52757 days. Add that to 1970-01-01 and you get 2114-06-12. The year (and month and day) are correct when interpreted via the chronology provided by datetime, which is an Earthly one. The datetime module uses the Unix epoch for dates, and so does the Earthly timescales it uses (UTC, TAI, etc.). The user should understand that by using the datetime module, they are reading Martian time via an Earthly (and Unix epoch centric) lens.

If a user wants a Martian interpretation of Martian time, they need a "martian" library, perhaps one that implements the Darian Calendar, and uses the Martian epoch of the MSD (Mars Sol Date) instead of the Unix epoch. This goes for any other chronology (any calendar here on Earth). The stdlib tutorial should clarify this. This "module" modularity was one of the principles behind the design and decoupling of the time::chrono and datetime modules.

#618 time::chrono: MTC gives wrong time a month ago

on ~sircmpwn/hare

~torresjrjr: FYI this crashes if there is no local leap seconds file:

Abort: /home/sircmpwn/sources/hare/time/chrono/timescale.ha:69:3: slice or array access out of bounds

Feel free to open a second ticket if you see fit.

#652 datetime: parse_tzif doesn't account for endianness 2 months ago

Comment by ~torresjrjr on ~sircmpwn/hare

RFC 8536 "The Time Zone Information Format (TZif)", section 3, paragraph 4, states:

NOTE: All multi-octet integer values MUST be stored in network octet order format (high-order octet first, otherwise known as big-endian), with all bits significant. Signed integer values MUST be represented using two's complement.

https://datatracker.ietf.org/doc/html/rfc8536#section-3

#651 datetime: complete arithmetic functionality 2 months ago

Ticket created by ~torresjrjr on ~sircmpwn/hare

General completion, refinement, and changes for add(), hop(), calculus, strategy, etc.