| 04:55 | <snek> | is human display for durations a solved problem anywhere? especially normalizing the units... |
| 04:55 | <snek> | the more i think about this the more complex it gets and the less sure i am that it could be generally solved |
| 15:05 | <ryzokuken> | snek welcome to my world |
| 15:05 | <ryzokuken> | the current version of the DurationFormat proposal can represent durations in mostly all forms that applications need |
| 15:38 | <snek> | the current version of the DurationFormat proposal can represent durations in mostly all forms that applications need |
| 15:58 | <ryzokuken> | does it support normalizing units? like if I just have a large quantity of seconds can it turn that into hours or weeks or whatever |
| 15:58 | <ryzokuken> | it can do that for subsecond units because those could be expressed as a fraction |
| 15:58 | <ryzokuken> | it could in the future do it up to hours |
| 15:59 | <ryzokuken> | but since a day may not have a set number of hours, it couldn't do further without a point of reference |
| 16:01 | <snek> | it has a point of reference!! it's intl api!!! |
| 16:01 | <snek> | or do you mean a timestamp |
| 16:02 | <ryzokuken> | no I mean a... |
| 16:02 | <ryzokuken> | yeah |
| 16:02 | <ryzokuken> | a ZonedDateTime for setting up the context for the calculations |
| 16:04 | <snek> | I guess I'll have to keep using the passable moment duration formatter |
| 16:04 | <snek> | it has some weird behavior though |
| 16:05 | <Andreu Botella> | I assume that wouldn't take leap seconds into account, right? |
| 16:05 | <Andreu Botella> | since IIRC UTC ignores them |
| 16:05 | <ryzokuken> | https://github.com/formatjs/formatjs/tree/d95d21f1ea10a190f45968e909323e9af6992921/packages/intl-durationformat |
| 16:05 | <ryzokuken> | there's this |
| 16:07 | <snek> | but if it doesn't normalize units it's not really usable |
| 16:07 | <snek> | I just have a unix timestamp |
| 16:07 | <ryzokuken> | ah right |
| 16:08 | <pipobscure> | You surely have a timestamp and some second timestamp to get a duration. |
| 16:08 | <snek> | I guess that is sort of a distinct operation |
| 16:08 | <pipobscure> | The difference is your duration and one of them is your reference |
| 16:08 | <snek> | I have a unix timestamp and I want to display the duration between it and the current time |
| 16:08 | <pipobscure> | Which means the duration is now-ts and the reference is now |
| 16:09 | <snek> | today I use moment but moment is kind of mid |
| 16:09 | <pipobscure> | Which is enough to let it normalize units |
| 16:09 | <snek> | yeah if something implemented that |
| 16:09 | <pipobscure> | It’s just tha if you have ONLY a duration of 2234234seconds you can’t normalise |
| 16:09 | <snek> | yeah that's the problem |
| 16:10 | <snek> | I just have a bunch of seconds. I want the computer to figure out the nicest way to display it, based on the users locale, reference point, or whatever else |
| 16:11 | <pipobscure> | Temporal.Duration.prototype.round should do that IIRC |
| 16:12 | <pipobscure> | And you can then send the result to Intl.DurationFormat |
| 16:13 | <snek> | hmmm |
| 16:13 | <snek> | that wants me to choose the unit though |
| 16:13 | <ryzokuken> | https://tc39.es/proposal-temporal/docs/balancing.html |
| 16:14 | <ryzokuken> | the largest one |
| 16:14 | <ryzokuken> | you can always go for largestUnit: "year" |
| 16:14 | <pipobscure> | The smallestUnit is optional I think |
| 16:15 | <devsnek> | oh it's just putting bounds on it I see |
| 16:15 | <pipobscure> | So with that combination of APIs you should be able to do exactly what you want. I think |
| 16:16 | <devsnek> | yeah that makes sense |
| 16:16 | <devsnek> | how many more years until ietf moves forward |
| 16:16 | <devsnek> | can we express it with Temporal.Duration |
| 16:24 | <ryzokuken> | how many more years until ietf moves forward |
| 16:24 | <ryzokuken> | we're planning to make an announcement at the next plenary |
| 16:25 | <snek> | I thought it was in a comment period for like 5 more months |
| 16:25 | <snek> | pleasant surprise |
| 16:25 | <ryzokuken> | it has been finally approved by the IESG |
| 16:26 | <ryzokuken> | https://www.rfc-editor.org/current_queue.php#draft-ietf-sedate-datetime-extended |