#microformats 2023-10-15

2023-10-15 UTC
gRegor joined the channel
#
angelo why are timezones normalized (colon removed) in a VCP context but not otherwise? see https://github.com/microformats/microformats2-parsing/issues/56#issuecomment-1160857892 and http://php.microformats.io/?id=20231015034742417
#
Loqi [preview] [gRegorLove] Testing current parsers: ```html <div class="h-event"> <h1 class="p-name">Happy 17th birthday microformats.org</h1> <p class="dt-start"> <time class="value" datetime="2022-06-20">20 June</time>, from <time class="value...
#
[jacky] Angelo: I wish I knew
#
[jacky] KevinMarks; yeah, that's a good first step but I'd want down to property level assignment
#
[jacky] Even for plain properties
#
j​kingweb angelo: Because dates in other contexts are not parsed at all, thus not normalized. Why _that_ is is a big shrug. I personally feel they should be. What's the point of having a date type if consumers each have to parse them themselves, sometimes?
#
[tantek] jkingweb, there is an open issue on this if you want to support changing it! https://github.com/microformats/microformats2-parsing/issues/12
#
Loqi [preview] [tantek] #12 should dt-* parsing do date and time parsing for all values?
[KevinMarks] joined the channel
#
[KevinMarks] Part of the challenge is that we support a broader range of date time values than most language's native type, as we support dates without times, and dates without years (for birthday's), so parsing needs to be smart and not add spurious precision, turning a date into an instant at midnight.
#
[tantek] ^ this is also why we don't use RFC3339
#
sknebel I think its also a question of parsing vs normalizing?
#
sknebel I think for parser implementations it could make sense to offer a flag that makes them return appropriate language datatypes where available
#
sknebel (similarly to how it's a sometimes-useful feature for a parser to return the HTML-DOM-datastructure it used for e- values)
#
sknebel but that's specific to the language environment what that exactly looks like
#
sknebel and thus IMHO(!) outside the parsing spec
#
sknebel normalizing then poses the question whats gained by it, if code consuming is likely understanding all the input formats anyways
#
j​kingweb Yeah, the parsing spec defines JSON output, so ultimately that's what you're restricted to.
#
sknebel (which is an assumption by me, admittedly - if people find "datetime parsers dont accept colons in datetimes" as a regular hurdle, that would be an argument for doing the extra work of normalization)
#
sknebel *colons in timezones
#
sknebel jkingweb - right, and that is one interface, but I dont think parsers should feel constrained to only offer that if there are smarter things to do in their specific ecosystem. but thats not something the spec can universally describe, because the ecosystems vary
#
[tantek] language datetime data types fail to represent actual human precision datetimes so no, I would strongly recommend against that. Or rather, conversion to language datetime data types is a information lossy operation
#
[tantek] That's probably worth a longer blog post
#
sknebel obviously only do it where appropriate, i.e. if the input is something you can express in the output
#
sknebel and what that is is again ecosystem-dependent
#
[KevinMarks] the tricky part is that we aren't just expressing instants or intervals, but potentially recurring intervals (ie 13th September every year) or more strictly 13th September every year between date of birth and date of death.
#
[KevinMarks] and that is fuzzy in timezones, so potentially lasts 50 hours
#
sknebel which again, some ecosystems can express, others can't
#
[KevinMarks] You could argue that an anniversary is a special type, and reduce others to intervals, but again langauges more often have time instanst than intervals
#
[KevinMarks] https://phire.place/@eaton/111160596012953987
[Jo] joined the channel
#
c​apjamesg 😄
jeremycherfas and btrem joined the channel
#
[tantek] sknebel it could be mildly entertaining to write up a critique of the Date (or equivalent) objects in the top 3-4 "ecosystems" (JS, PHP, Java, Python, Ruby?) and how they fail to express numerous human use-cases for dates & times
#
sknebel afaik modern Java is quite good, because someone went through and made types for all(?) the ISO8601-cases? the rest, not so much
#
angelo all datetimes (plaintext and VCP) get passed through the same normalization function in mf2py https://github.com/microformats/mf2py/blob/main/mf2py/datetime_helpers.py#L21
#
[tantek] angelo, that's worth noting in issue 12 noted above! https://github.com/microformats/microformats2-parsing/issues/12 it's a good reason to support that change
#
Loqi [preview] [tantek] #12 should dt-* parsing do date and time parsing for all values?
GWG joined the channel