Can I use HTML time tag as below?
<time>9:09 PM</time>
My confusion is around the "PM" , whether I can specify it like this OR time is only for displaying 24 hr clock.
According to the W3C definition of the <time> tag, any content which represents a time without specifying also a day must be a valid time-string which it defines as follows:
1.Two ASCII digits, representing hour, in the range 0 ≤ hour ≤ 23
2.A ":" (U+003A) character
3.Two ASCII digits, representing minute, in the range 0 ≤ minute ≤ 59
4.Optionally (required if second is non-zero):
1.A ":" (U+003A) character
2.Two ASCII digits, representing the integer part of second, in the range 0 ≤ s ≤ 59
3.Optionally (required if second is not an integer):
1.A 002E FULL STOP character (.)
2.One, two, or three ASCII digits, representing the fractional part of second
So no, the 12-hour time format is non-standard. The purpose of the semantic tags in HTML5 is to make the document machine-readable, which means when you want the tags to serve their purpose, you need to follow the standard accurately. In this case the standard does not allow any AM or PM.
However, when you use the datetime-attribute of the time-tag, you can write anything you like into the text content, because in that case the datetime will be considered the machine-readable version and the text-content the human-readable version. So this:
<time datetime="21:09">9:09 PM</time>
would be valid, and so would be
<time datetime="21:09">a few minutes past nine in the evening</time>
See http://www.w3.org/html/wg/drafts/html/CR/text-level-semantics.html#the-time-element:
A time consists of a specific time with no time-zone information, consisting of an hour, a minute, a second, and a fraction of a second.
Examples in the draft include
<time>14:54</time>
where others show datetime is needed for alternative notations:
<p><time itemprop="datePublished" datetime="2009-10-09">3 days ago</time></p>
<p><time itemprop="commentTime" datetime="2009-10-10">15 minutes ago</time></p>
<p>Posted <time itemprop="datePublished" datetime="2009-10-10">Thursday</time>.</p>
<FOOTER> <!-- footer for article -->
<P>Published <TIME DATETIME="2009-10-21T18:26-07:00">on 2009/10/21 at 6:26pm</TIME></P>
</FOOTER>
Related
I have at my disposal 16 bits. Of them, 4 bits are the header and cannot be touched. This leaves us with 12 bits. I would like to encode date and time data into them. These are essentially logs being sent over LPWAN.
Obviously, it's impossible to encode proper generic date and time into it. Since the unix timestamp uses 32 bits, and projects like Compact Time Format use 5 bytes.
Let's say we don't really need the year, because this information is available elsewhere. Let's also say the time resolution of seconds doesn't have to be super accurate, so we can split the seconds into 30 second intervals. If we were to simply encode the data as is then:
4 bits month (0-11)
5 bits day (0-31)
5 bits hour (0-23)
6 bits minute (0-59)
1 bit second (0,30)
-----------------------------
21 bits
21 bits is much better than 32. But it's still not 12. I could subtract one bit from the minutes (rounding to the nearest even minute), and remove the seconds but that still leaves us with 19 bits. Which is still far from 12.
Just wondering if it's possible, and if anyone has any ideas.
12 bits can hold 2^12 = 4096 values, which feels pretty tight for a task. Not sure much can be done in terms of compressing a date time into a 4096 number. It is too little space to represent this data.
There are some workarounds, none of them able to achieve what you want, but maybe something you could use anyway:
Split date and time. Alternate with some algorithm between sending date/time, one bit can be used to indicate what data is being sent. This leaves 11 bits to encode either date or time. You could go a bit further and split time like this as well. Receiving side can then reconstruct a full date time having access to the previously received data.
You could have a schema where one date packet is sent as a starting point, and subsequent packets are incremented in N-second intervals from the start of the epoch
Remove date time from data completely, saving 12 bits, but send it periodically as a stand-alone heartbeat/datetime packet.
You could try compressing the whole data packet which could allow using more bits to represent date time and still fit into a smaller overall packet size
If data is sent at reasonable fixed intervals, you could use a circular counter of an interval of N seconds, this may work if you have few devices and you can keep track of when they start transmitting. For example a satellite was launched on XYZ date time, it send counter every 30 seconds, we received counter value of 100, to calculate date we use simple math XYZ + 30*100 seconds
No. Unless you'd be happy with representing less than a span of a day and a half. You can just count 4096 30-second intervals, and find that that will cover 34 hours and eight minutes. 4096 two-minute intervals is just four times that, or five days, 16 hours, and 32 minutes. Still a small fraction of a year.
If you can assure that the difference between successive log entries is small, then you can stuff that in 12 bits. You will need a special entry to give an initial date, and maybe you could insert such an entry when the difference betweem successive entries is too large.
#oleksii has some other good suggestions as well.
Is possible encrypt 30 digit number into 10 digit number, i have number like
23456-32431-23233-76543-98756-54543 i need look like 10 digit encrypt format.
Is possible encrypt 30 digit number into 10 digit number,
Purely mathematically - you cannot. Still we are assuming you want to represent 30 decimal digits of any value using 10 decimal digits. You simply want to put a pint into a shot glass.
Anything, i need compressed the digit.
Compression would be possible if some of the stated assumptions would be not valid.
If you could represent the output as text (any character or binary), you could encode the decimal value to binary/base64 form which would allow shorten representation (still no to 1:3 ratio)
Compression would work well, if the input values (or part of the input) would not be random. If digits or significant part of the input have not uniform distribution or part of the input would represent a limited counter, then the parts or digits could be represented with limited number of bits.
You may know more about your data, so only you could tell anything about the data distribution.
curiosity, how goo.gl & bit.ly working?
The "shortening" sites are a key-value storage, mapping a generated short value to stored full url. So it's mapping, not any compression.
For passing times in JSON to/from a web API, why would I choose to use an ISO8601 string instead of simply the UTC epoch value? For example, both of these are the same:
Epoch = 1511324473
iso8601 = 2017-11-22T04:21:13Z
The epoch value is obviously shorter in length, which is always good for mobile data usage, and it's pretty simple to convert between epoch values and the language's local Date type variable.
I'm just not seeing the benefit to using an ISO string value.
Both are unambiguous and easy to parse in programs. The benefit of epoch like you have mentioned is that it is smaller and will be faster to process in your program. The downside is it means nothing to humans.
iso8901 dates are easy to read on their own and don't require the user to translate a number in to a recognizable date. The size increase in iso8601 is unnoticeable when compared to much much larger things like images.
Personally I would pick ease of reading over speed for an API as it will cut down on debugging time while inspecting values sent and received. In another situation such as passing times around internally you may wish to choose the speed of an integer over text so it depends which you think will be more useful.
Unix/Epoch Time
+ Compact
+ Easy to do arithmetic actions without any libraries, i.e. var tomorrow=now()+60*60*24
- Not human-readable
- Cannot represent dates before 1 January 1970
- Cannot represent dates after 19 January 2038 (if using Int32)
- Timezone and offset are "external" info, there is ambiguity if the value is UTC or any other offset.
- Officially the spec supports only seconds.
- When someone changes the value to milliseconds for better resolution, there is an ambiguity if the value is seconds or milliseconds.
- Older than ISO 8601 format
- Represents seconds since 1970 (as opposed to instant in time)
- Precision of seconds
ISO 8601 Time
+ Human readable
+ Represents instant in time, as opposed to seconds since 1970
+ Newer then Unix time format
+ Specifies representation of date, time, date-time, duration and interval!
+ Supports an offset representation
+ Precision of nanoseconds
- Less compact
- For any arithmetic actions, reach library is required (like java.time.OffsetDatetime)
I was scanning some stylesheets when I noticed one which used a linear-gradient with rgba() color-stops in which the rgba numbers used multiple instances of 0 instead of just a single 0:
background-image:linear-gradient(to top left, rgba(000,000,000,0.1),rgba(100,100,100,1));
I hadn't seen multiple zeroes (instead of a single zero) occupying a single slot in the rgb/a color space before, but confirmed on CodePen this is valid. I then looked up the W3C definition of number here.
To make a long story short, after some more poking and digging, I didn't realize I could prepend an indeterminate number of zeroes to a length and get the same result as with no zeroes prepended, like this:
/* The two squares generated have equivalent width and height of 100px - for giggles, I also extended the same idea to the transition-duration time */
<style>
div.aaa {
width:00000000100px;
height:100px;
background-image:linear-gradient(to top left,rgba(000,000,000,0.1),rgba(100,100,100,1));
transition:1s cubic-bezier(1,1,1,1)
}
div.bbb {
width:100px;
height:000000000000000000000000000000000100px;
background-color:green;
transition:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001s cubic-bezier(1,1,1,1)
}
div:hover { background-color:red }
</style>
<div class="aaa"></div>
<div class="bbb"></div>
It's difficult to directly verify these numbers are equivalent representations, because using a scripting language:
/* PHP */
$x = 100;
$y = 00000000000100; // problem is PHP treats this as an octal number
echo ($x == $y) ? 'true' : 'false'; // echoes the string ---> false
/* Javascript */
var x = 100;
var y = 00000000000100; // also treats this as an octal number
var res = (x == y) ? 'true' : 'false';
alert(res); // alerts ---> false
These examples suggest to me that CSS does not treat e.g. 0000100 as an octal number, but rather as a decimal (or at least as non-octal numbers) since the magnitude of the width, height, and transition-duration for the html elements generated above appear to be identical.
Extending this CSS approach to any property and any unit, e.g., time,
Is any unit-containing CSS property value prepended with any positive number of zeroes syntactically equivalent to the same value without any prepended zeroes?
I have to admit I found this question interesting.
https://www.w3.org/TR/CSS21/syndata.html
The css 2 syntax spec says:
num [0-9]+|[0-9]*\.[0-9]+
Note that 000000000000000037.3 meets this rule and definition, a series of numbers between 0 and 9, optionally followed by a . and a further series of numbers from 0 to 9.
The css 3 spec goes on:
https://www.w3.org/TR/css3-values/#numbers
4.2. Real Numbers: the type
Number values are denoted by <number>, and represent real numbers,
possibly with a fractional component.
When written literally, a number is either an integer, or zero or more
decimal digits followed by a dot (.) followed by one or more decimal
digits and optionally an exponent composed of "e" or "E" and an
integer. It corresponds to the production in the CSS
Syntax Module [CSS3SYN]. As with integers, the first character of a
number may be immediately preceded by - or + to indicate the number’s
sign.
https://www.w3.org/TR/css-syntax-3/#convert-a-string-to-a-number
This I believe roughly explains how a css parser is supposed to take the css value and convert it to a number:
4.3.13. Convert a string to a number
This section describes how to convert a string to a number . It
returns a number.
Note: This algorithm does not do any verification to ensure that the
string contains only a number. Ensure that the string contains only a
valid CSS number before calling this algorithm.
Divide the string into seven components, in order from left to right:
A sign: a single U+002B PLUS SIGN (+) or U+002D HYPHEN-MINUS (-), or the empty string. Let s be the number -1 if the sign is U+002D
HYPHEN-MINUS (-); otherwise, let s be the number 1.
An integer part: zero or more digits. If there is at least one digit, let i be the number formed by interpreting the digits as a
base-10 integer; otherwise, let i be the number 0.
A decimal point: a single U+002E FULL STOP (.), or the empty string.
A fractional part: zero or more digits. If there is at least one digit, let f be the number formed by interpreting the digits as a
base-10 integer and d be the number of digits; otherwise, let f and d
be the number 0.
An exponent indicator: a single U+0045 LATIN CAPITAL LETTER E (E) or U+0065 LATIN SMALL LETTER E (e), or the empty string.
(-), or the empty string. Let t be the number -1 if the
sign is U+002D HYPHEN-MINUS (-); otherwise, let t be the number 1.
An exponent: zero or more digits. If there is at least one digit, let e be the number formed by interpreting the digits as a base-10
integer; otherwise, let e be the number 0.
Return the number s·(i + f·10-d)·10te.
I think the key term there is a base-10 number.
Note that for other possible situations where the starting 0 is meaningful, you have to escape it for it to function as something other than a simple number, I believe, if I read this spec right:
https://www.w3.org/TR/css-syntax-3/#escaping
Any Unicode code point can be included in an identifier or quoted
string by escaping it. CSS escape sequences start with a backslash
(\), and continue with:
Any Unicode code point that is not a hex digits or a newline. The escape sequence is replaced by that code point.
Or one to six hex digits, followed by an optional whitespace. The escape sequence is replaced by the Unicode code point whose value is
given by the hexadecimal digits. This optional whitespace allow
hexadecimal escape sequences to be followed by "real" hex digits.
An identifier with the value "&B" could be written as \26 B or \000026B.
A "real" space after the escape sequence must be doubled.
However, even here it appears the starting 0's are optional, though it's not crystal clear.
The CSS specs were while obtuse fairly clear, which isn't always the case. So yes, numbers are made from strings of digits, and can have decimals as well, and are base 10, so that means the leading zeros are simply nothing.
I speculate as well that because the specs further state that no units are required when the number value is 0, that in fact, a leading zero may mean null, nothing, internally, though obviously you'd have to look at css parsing code itself to see how that is actually handled by browsers.
So that's kind of interesting. I think that probably because css is a very simple language, it doesn't do 'clever' things like php or javascript do with leading zeros, it simply does what you'd expect, treat them as zeros, nothing.
Thanks for asking though, sometimes it's nice to go back and read the raw specs just to see how the stuff works.
With ISO8601, is there a way to specify a repeating interval which starts at a given time for any day, and repeats over time in that day?
For example, does the following hold:
R2/T09:00:00Z/PT1H = R/2000-01-01T09:00:00/P1D + R/2000-01-01T10:00:00/P1D?
Or is the former not correct under the standard?
The motivation behind this is to run a task at 9am and 10am every day.
No, Iso 8601 cannot irregular repetitions. You would need evaluate/run both of those expressions.
Cron expressions would be a better option as it is widely supported, especially for running tasks. You can find cron expression builders on the web and a library for every language (and OS support with crontab in Unix systems). This expression would handle your use case 0 0 9,10 ? * * * and would run at 9 and 10 am of every day of every year.
Sorry for the response 2 years later.