I'm working on an a11y feature to read out time stamps in this format:
<div>3:20</div>
And I'd like that to read as "3 minutes 20 seconds"
My coworker found that if I add an aria label of "0h 3m 20s" to the div, it reads it as "zero hours 3 minutes 20 seconds"
However, if I leave off the hours, it reads "3 meters twenties." Similarly, if I leave off the minutes (1h 20s) it reads "1 h twenties"
Is there any way I can have it read this type of strings without the hours (most are under an hour). In general, is there any sort of documentation for having the screen reader read these kinds of strings? Or is it best practice to just spell out the words in the aria label? Thank you.
FYI I'm using Chromevox.
You have to consider that ChromeVox is not a screenreader used by a lot of people (except some developers). See WebAIM Screenreader survey
The problem with your question is that it's still possible to find a hack to announce the time in a different format (see answer to your previous question) using some "sr-only" hack but it will never be accessible as long as the visible time is not accessible.
Nobody can guess that "3:20" means "3 minutes 20 seconds" and not "3 hours 20 minutes". Providing that information for screenreaders should not prevent to provide this information for everyone.
Using some more accessible notation like "3 min 20" instead of "3:20" would be very helpful and more accessible.
aria-label won't be of any help for standard screenreaders who won't announce this unless it's on an interactive element (link, button, ...). By the way, using aria-label the best thing would be to write "3 minutes and 20 seconds"
Related
I'm writing an iCAL file. I work on a cruise ship and the file will basically be my itinerary for the next 6 months, which I want to share with other crew members, to be displayed on our phones (a mixture of iPhones and Android phones). I want to included the name of the port we visit, and the arrival and departure times. So far, so easy.
BUT, on a cruise ship we pass through different time zones on an almost daily basis. Some people use local carrier info to set their phone timezones, others adjust the timezone manually, and some don't bother doing either. I tried this once before, but got very confused with TIMEZONE formats: whether to use UTC with a 'Z' prefix, whether to specify the country codes, etc.
HOWEVER, a recent bit of googling turned up the 'floating' DTSTART and DTEND format, aka 'Local Time', which seems to do away with all the region and timezone specifications. So, am I right in thinking the following will work?
(Source data: 23 Nov, Rio De Janeiro, 8:00am to 6:00pm,
and 25 Nov, A Different Port, 10:00am to 8:30pm)
BEGIN:VCALENDAR
VERSION:2.0
PRODID: MyNameHere
BEGIN:VEVENT
UID:milesmuso.mf#qwertyqwertyqwerty.com
DTSTAMP:20171123T080000Z
DTSTART:20171123T080000
DTEND:20171123T180000
SUMMARY:Rio De Janiero
END:VEVENT
.
BEGIN:VEVENT
UID:milesmuso.mf#qwertyqwertyqwerty.com
DTSTAMP:20171125T100000Z
DTSTART:20171125T100000
DTEND:20171125T203000
SUMMARY:Another Port
END:VEVENT
.
.
BEGIN: VEVENT
(next event here)
END VEVENT
END:VCALENDAR
And if that syntax IS correct, then do I still need to specify DTSTAMP:20171123T080000Z with the 'Z' suffix? (something I read on https://www.kanzaki.com/docs/ical/dtstamp.html said that the 'Z' suffix is mandatory, even though I don't WANT to use UTC - I just want floating start and end times.)
Also, should the DTSTAMP time be the same as the DTSTART time for each event, or do I use the same one for each event?
I hope you can help
Thanks
Miles,
Musician,
Celebrity Infinity
Using floating time means that the timezone that's actually used, is actually in the timezone of the viewer of the event.
So if you schedule something at 8PM floating time, and: "User A" has their timezone set to Eastern, and it's 7:55pm, the event will occur 5 minutes from now, then user "B" who has their phone set to Central time will see that the event starts one hour + 5 minutes from now.
In other words, using floating time means that the actual time as viewed by the user is going to depend on the viewer of the event.
This is not what you want. Because you are going to arriving and departing at fixed points in time. You really have two options:
Use UTC.
Use local time + a timezone of the port
UTC might be simpler in your case, but there's a caveat. You mention Rio De Janairo, and Brazil's treatment of DST (daylight savings time) has not been stellar.
So it's possible that you plan to arrive your ship at 2PM localtime somewhere, but a few weeks before you do, the Brazilian government decides to postpone or scrap daylight savings time that year. The question is then, does the boat depart an hour later (still 2PM local time) or does it depart at the exact same time from a UTC perspective?
You might consider this an edge case and make adjustments if needed, when they do but I thought it was worth talking about this scenario.
Anyway, ignoring that, both "local time + TZ" or "UTC" will probably be good enough for you. If you use "America/Sao_Paulo" for a departure time, and people:
Automatically got a time and timezone from a carrier, it will "just work"
Manually changed their timezone, it will "just work"
I think I would prefer the local time + TZ because it's the most 'accurate' representation of the event.
I'm reading SMS using AT commands much like in this tutorial. When I read the messages, I want to know how "old" are those SMS. The information at which the SMS was received by the SMSC is contained in the SMS, in plain text as:
+CMGL: 1,"REC UNREAD","+85291234567",,"07/02/18,00:05:10+32"
Reading text messages is easy.
How should I parse this "07/02/18,00:05:10+32" ? I mean, what does the +32 mean ? It cannot be a 32 hours offset from UTC.
Also, if an SMS is sent, say, from Japan to France, what would be the hour displayed when listing the SMS ? The hour from the Japanese SMSC ? From the French SMSC ? How can I convert them to UTC to reliably compute the time that has passed from the moment the SMS was sent (reached the SMSC) to the moment I read it ?
Not really looking for implementation specific answers here, but if it matters, I'll do the maths in shell script
It represents the offset in quarters of an hour.
This link will help you to resolve the problem.
http://www.developershome.com/sms/cmgsCommand2.asp
Regards,
This answer confirms eBusians's answer, but shows how to arrive at the same conclusion using authoritative references instead of relying on random web pages (some are good, but many are not). The text on the linked web page is not incorrect, but it is only about the AT+CMGS command and not the AT+CMGL command as asked here, so then you have to guess/assume that they are the same format which is not a good approach.
The document describing the AT+CMGL command is the 27.005 standard (or your modem manufacturer's own specific product documentation). It defines the syntax as
+CMGL: <index>,<stat>,<oa/da>,[<alpha>],[<scts>][,<tooa/toda>,<length>]
<CR><LF><data>
And <scts> is defined as
3GPP TS 23.040 [3] TP-Service-Centre-Time-Stamp in time-string format (refer <dt>)
And <dt> is defined as
3GPP TS 23.040 [3] TP-Discharge-Time in time-string format:
"yy/MM/dd,hh:mm:ss±zz", where characters indicate year (two last
digits), month, day, hour, minutes, seconds and time zone. E.g. 6th of
May 1994, 22:10:00 GMT+2 hours equals to "94/05/06,22:10:00+08"
At this point I did not bother to dig deeper into the 23.040 specification as the 2 <==> 8 relation in the example is consistent with eBusians's answer and I have no reason to doubt its correctness.
I'm trying to determine what the default time zone is for an XML Schema dateTime, when it is not specific. The time zone portion at the end is optional and it may be omitted:
2013-01-11T16:02:55
I read in this answer that the time zone is undetermined when not specified. I read in the comments to this question that the default is UTC if not specified. I also read through the W3C definition and that didn't give me a clear answer.
Can any experts point me to where this is specified?
An unspecified time zone is exactly that - unspecified. No more, no less. It's not saying it's in UTC, nor is it saying it's in the local time zone or any other time zone, it's just saying that the time read from some clock somewhere was that time.
The fact that it originated from an xs:dateTime doesn't really play into it at all. It's just an ISO 8601 date + time (without time zone) value.
It really depends on what you do with this value as to what it actually means.
In the real world, you probably should avoid values like this when working with timestamps - that is, the exact moment something occurs. For those you should specify an offset like -07:00, or a Z to indicate UTC.
Where an unspecified value might have legitimate usage:
When scheduling future events by recurrence pattern, and paired with a time zone (such as America/New_York). For details, see other answers of mine here, here, and here.
When referring to a "floating" time, that might be at a different instantaneous moment in multiple time zones. Example: A network television show that starts at 7:00 PM. The Eastern US would see it before the Western US, but it still airs at the same "floating" time in each zone.
When the time zone is already known by some other mechanism, and there is no risk of daylight saving time ambiguity, or when the risk is accepted and determined inconsequential.
In XSD 1.0, sec. 3.2.7 says (sec. "untimezoned times are presumed to be the time in the timezone of some unspecified locality". That seems to me a pretty clear indication that they don't default to UTC for validation purposes, and also that they don't default to local time for any fixed locality (e.g. the server's time). Sec. 3.2.7.4 describes (in some detail and at tedious length) that the ordering relation on dateTime is a partial order, not a total order, because (for example) the untimezoned value 2000-01-20T12:00:00 is neither definitely earlier than, nor definitely later than, nor definitely equal to, 2000-01-20T12:00:00Z.
XSD 1.1 revises the text of the discussion a good deal, but it comes to the same thing.
I believe that this is consistent with the rules in ISO 8601.
What an application makes of untimezoned values, and what other specs do with them, is a separate issue, to be answered application by application and spec by spec. But for XSD purposes, it's clear that there is no default timezone.
"The events depicted are artificial in that processes do not always experience them, but they illustrate various state transitions."
I am unable to understand the perfect meaning of this sentence. I assume this is because of I am not native English speaker or I don't have much experience about processes and their states. What the above sentence tries to convey? Is it saying that The process which is first time experiencing the state will consider it as artificial or some thing more. Kindly guide me so that I am able to clear what is the meaning of this sentence. Following is the some more information about the line. Following will help you to find the line in book if you want to read the other sentences with this sentences.
Name of the Book: "The Design of the UNIX operating system"
Author : "M.J.Bach"
Chapter : " 6 - The Structure of Processes"
Page number : "147"
Topic : "6.1 - Process states and transitions"
paragraph number : "2 from the beginning of the page"
Line number related to paragraph : "2 line in paragraph."
I don't have my copy of Bach handy at the moment, so I may be a bit off base on what I remember, but I think what it is trying to say is that it may help conceptually to think of a process going from state A to state B and then to state C, but a real-world OS may choose to go directly from A to C and just perform the steps for both transitions at once, because there may not be any real reason to actually have a state B and allow processes to live in that state.
If I wanted to work using dates and time going millions of years into the past/future how would I do it in C/C++/C#?
For example say I was working on an algorithm to see if a comet was going to hit the earth? Are there commercial or open source libraries that do this?
Most DateTime values only work for a few years. Unixes will run out in only 2038!.
Tony
Astronomers use their own calendar, different from the civil, Gregorian calendar.
Astronomical Julian Dates are what they use.
Look at http://en.wikipedia.org/wiki/Julian_day
Here's a typical package: Solar Clock.
You can't work out future UTC dates down to the second, because of the existence of leap seconds (one of which is scheduled for December 31, a couple of weeks from now). No one knows when leap seconds will be added to the calendar, because no one knows the rate at which the Earth's rotation will continue to slow in the future.
Well, not to be blunt or anything, but if it will hit the earth in like 1700 years, I don't think we'll need to know the actual date.
Unless it's a tuesday.
Never could get the hang of tuesdays.
If the time span offered by typical datetime variables is too small, you have two options:
Using a variable with a bigger scope (i.e. more bits)
Allowing for less precision
Which one you should choose depends on what exactly you want to do. But in general, my advice is option number 2. When we are talking about centuries or millenia, milliseconds are usually not that important...
When it comes to astronomical events, it doesn't matter which part of the earth is facing the Sun, i.e. has daylight. Therefore, calendars and dates are irrelevant too. You should simply use time. A 64 bit time_t for instance is quite sufficient.
Even when you do use time, keep in mind that 3-body systems (like Earth-Sun-Jupiter) are chaotic. Predicting the position of the Earth in the far future has a rather large margin of error.
A 64-bit time_t will work until the year 292,277,026,596.
You just need more bits to store the value and/or use larger increments of time to represent by the timestamp. Instead of ms, do years, then possibly use a math library/API designed for very large numbers if that isn't enough (and depending on your precision requirements) or use floating point.
The DateTime object in C# goes from 1.1.0001 to 12.31.9999. It's even more limited in SQL Server where the earliest date is something like 1735.
You're pretty much going to have to write something yourself or try to scrounge something from someone else. Going forward is probably easier (except the leap second thing.) There is some pretty good info on calendars here.
I think the problem is not knowing whether the comet is going to hit on a Friday or Sunday but if the comet is or isn't going to hit. I guess this means that you could model time in 1000ths of a second as a 64bit long long type. You can resolve 213 Billion Years. You can then have a routine which maps this back to meaning full-ish dates...