-
Notifications
You must be signed in to change notification settings - Fork 54
Format duration timestamp correctly for Radio Schedules #3065
Comments
Can we also check with Jon/UX about formatting of the duration for each service? |
And we don't necessarily want duration to have the same formatting as the start time, just that it is within a time element :) |
"And we don't necessarily want duration to have the same formatting as the start time, just that it is within a time element :)" - Time element for the displayed start time only? Not the visually hidden start time @tochwill ? |
That's correct! My understanding is we have the start time as a correctly formatted string within the H3 for visually hidden, use the semantic time element for the start time in the visual start time above the card (but this is marked as aria-hidden), and the duration in a time tag at the bottom of the card (and we have the translated word 'Duration' with the announced text). We've just gone through the issues again to make sure the requirements are clear as some things got confused in the initial ticket that was created. |
Sounds good @tochwill Just a typo above "That's correct! My understanding is we have the start time as a correctly formatted string within the H3 for visually hidden..." |
I'm don't think timestamp container is set up to handle durations (there's an example here: https://css-tricks.com/time-element/) - we aren't going to be using a unix timestamp for the duration, just a formatted duration (the format is MM:SS in the designs, but might differ by service?). We could use the timestamp component though? |
@tochwill good point about the timestamp container, will update the ticket description. Though as I understand correctly, initially we will get duration as unix time? Since it will be |
Aha, so the unix timestamp measures the time since the 'unix epoch' (Midnight 1 January 1970). If we take one away from the other, we will have worked out the duration, but that's not a 'unix timestamp' anymore - if we treat this as a unix timestamp and pass it into the formatters we use for that, we'll end up with the date that is the unix epoch + our duration (So, 00:20 on 1st January 1970 for a 20 minute programme), if that makes sense? |
We also get the duration from ares in this format: |
Is your feature request related to a problem? Please describe.
The duration timestamp in the program-card does not use the correct time format.
Describe the solution you'd like
Create the duration timestamp using the
Timestamp
component in order to transform unix time into a correct timestamp for the program card button.Make sure that screen readers are announcing the duration correctly : Announced text: Duration 30,00
Describe alternatives you've considered
N/A
Testing notes
[Tester to complete]
Dev insight: Will there be any potential regression? etc
The text was updated successfully, but these errors were encountered: