What is the correct format for a html5 <time datetime="" /> attribute? Do days come before month or vice versa:
<time datetime="yyyy-dd-mm"></time>
or
<time datetime="yyyy-mm-dd"></time>
where
mm = Month (ie 01)
dd = Day (ie 20)
It's yyyy-mm-dd, in order to comply with ISO-8601 and general sanity.
From the W3C proposed recommendation:
Note: While the formats described here are intended to be subsets of the corresponding ISO8601 formats, this specification defines parsing rules in much more detail than ISO8601. Implementors are therefore encouraged to carefully examine any date parsing libraries before using them to implement the parsing rules described below; ISO8601 libraries might not parse dates and times in exactly the same manner. [ISO8601]
That's the simplest indication I could find in the recommendation, although there's also the "dates" section which indicates that a date is a valid-month-string followed by a - and then a day, and valid-month-string is defined as:
A string is a valid month string representing a year year and month month if it consists of the following components in the given order:
Four or more ASCII digits, representing year, where year > 0
A "-" (U+002D) character
Two ASCII digits, representing the month month, in the range 1 ≤ month ≤ 12
You should use the format of yyyy-mm-dd
the second one is correct :
<time datetime="yyyy-mm-dd" />
Related
I'm working on tables obtained from a PervasiveSQL database and I have some trouble managing dates.
In some of the fields dates are recorded in the format we use in Italy, dd/mm/yyyy, but in others are recorded in a format I can't understand, something like this:
Start_Date 132384788
Last_Tx_Date 132385052
Last_Tx_Time 252711936
What kind of format is it?
How can I convert it in a human readable one?
I think that Start_Date could be August 8 2020 but I'm not sure.
Thanks for any help!
I tried to copy and paste tables in an Excel file but automatic dates conversion did not work.
The Start_Date and Last_Tx_Date fields look to be Btrieve Date fields. If you set the data type for that field in the DDFs to Date, it should show a human readable field. However the Last_Tx_Time field is a Btrieve Time (not timestamp) type.
From the Actian Zen v15.10 documentation (https://docs.actian.com/zen/v15/#page/sqlref/sqldtype.htm#ww136646):
Date:
The DATE key type is stored internally as a 4-byte value. The day and the month are each stored in 1-byte binary format. The year is a 2-byte binary number that represents the entire year value. The MicroKernel places the day into the first byte, the month into the second byte, and the year into a two-byte word following the month.
An example of C structure used for date fields would be:
TYPE dateField {
char day;
char month;
integer year;
}
The year portion of a date field is expected to be set to the integer representation of the entire year. For example, 2,001 for the year 2001.
Time:
The TIME key type is stored internally as a 4-byte value. Hundredths of a second, second, minute, and hour values are each stored in 1-byte binary format. The MicroKernel places the hundredths of a second value in the first byte, followed respectively by the second, minute, and hour values. The data format is hh:mm:ss.nn. Supported values range from 00:00:00.00 to 23:59:59.99.
I'm trying to specify a format for week day and time combination. Since I've been using ISO 8601 for date time representation, I'm trying to fit weekday/time format as per 8601. It can be easily represented as
1T10:45
where 1 is the week day number (Monday as per 8601). But I'm not sure if this is a valid ISO 8601 representation. Any advice would be very helpful.
Thanks
ISO 8601 defines values for the days of the week but not a format representing only the day of the week (e.g. for unbounded recurring times). You should feel free to adopt the ISO 8601 notation for the day of the week but accept that whatever format you choose will not comply with ISO 8601 unless it specifies the year, the week number, and the day of the week within that week (as in the example 1985-W15-5 from ISO 8601).
2015-03-04T5:06:07.000+0000
I have access to date formats as above, and intend to compare and sort them in ascending order. This is OK when I use a simpler date format in the Playground, but the actual json data bemuses me as I cannot find out what 'T5' refers to, even after looking through the relevant Unicode page.
I had assumed it was a timezone reference, but this would be Z, and I don't think it would be after the day anyway.
"T" is just a separator between the date and time in ISO-8601. It means the strings following it is a Time.
The timezone part is "+0000" i.e. UTC.
So your date format just mean "2015 March 4th, 05:06:07am, at timezone UTC±0".
The letter "Z" means UTC (i.e. Zulu time) and only appears at the end of the string i.e. 2015-03-04T05:06:07.000Z
I've discovered an issue with some of data being stored in MongoDB. We have a field that stores a Date, and normally this includes values like ISODate("1992-08-30T00:00:00.000Z") or ISODate("1963-08-15T00:00:00.000Z"). That's nice and straight-forward; I can easily look at those dates and see August 30, 1992 or August 15, 1963.
However, I've noticed a couple of entries where the date looks something like this instead:
Date(-61712668800000)
I'm honestly not sure how the data got persisted that way in the first place, as it should have been stored the former way. And I'll have to address the software bug with my code that is intermittently causing it to be stored that way.
However, the bigger problem is what to do with data entries that look like that. I'm not even sure what date that was supposed to be. My first assumption is that it's just milliseconds, like a UNIX timestamp or something, but that's not right. Even if I flip the negative sign and remove some of the trailing zeros, that still ends up being a date way in the future (e.g. July 23, 2165), and that's not correct. It should be a date in the past.
And the other big problem is that I'm not sure how to even search for this in the database. I can't utilize a $type query because the type is still 9 (i.e. it still thinks it's a "Date").
Has anyone else encountered these weird date entries before? How can I find them? And how can I recover the actual date from them?
The problem seems to be that your code is storing dates prior to the epoch, which are furthermore so far into the past that they cannot be represented using an ISODate wrapper:
As per the documentation
(emphasis added)
Date
BSON Date is a 64-bit integer that represents the number of
milliseconds since the Unix epoch (Jan 1, 1970). This results in a
representable date range of about 290 million years into the past and
future.
The official BSON specification refers to the BSON Date type as the
UTC datetime.
Changed in version 2.0: BSON Date type is signed. [2] Negative values
represent dates before 1970.
Although not explicitly stated in the Mongo documentation, it appears that they are following a strict interpretation of the ISO 8601 standard and not one of the variants which are allowed "by trading partner agreement" based on what I found at wikipedia
Years
YYYY ±YYYYY ISO 8601 prescribes, as a minimum, a
four-digit year [YYYY] to avoid the year 2000 problem. It therefore
represents years from 0000 to 9999, year 0000 being equal to 1 BC and
all others AD. However, years prior to 1583 are not automatically
allowed by the standard. Instead "values in the range [0000] through
[1582] shall only be used by mutual agreement of the partners in
information interchange."[9]
To represent years before 0000 or after 9999, the standard also
permits the expansion of the year representation but only by prior
agreement between the sender and the receiver.[10] An expanded year
representation [±YYYYY] must have an agreed-upon number of extra year
digits beyond the four-digit minimum, and it must be prefixed with a +
or − sign[11] instead of the more common AD or BC (or the less widely
used BCE/CE) notation; by convention 1 BC is labelled +0000, 2 BC is
labeled -0001, and so on.[12]
If you read through the rest of the article you will also see that the reason the number of digits must be pre-defined is so that the date can be stored unambiguously without using separator characters such as "-" between the components.
In MySql I can use YEARWEEK() to receive the week and the related year of this week in one string. (E.g. SELECT YEARWEEK('1987-01-01'); which leads to "198653").
Is there anything like that in Oracle10g?
I only know about the TO_CHAR function. But if I use TO_CHAR(sysdate, 'YYYYIW'); I receive 198753 and not 198653. So, how I am able to calculate this correctly?
Does using IYYYIW format with TO_CHAR() make any difference? Note the "I" in the beginning instead of first "Y", it is for 4-digit year based on the ISO standard.
I can't reproduce your example that Oracle returns 198753.
select TO_CHAR(DATE '1987-01-01', 'YYYYIW') from dual returns 198701 for me which is correct according to the ISO definition of week numbers.
Oracle has another format mask WW (instead of IW) that uses the week where the first day of the year is in as week #1 - which again would return week number 1 for the January 1st.
Have a look here: http://en.wikipedia.org/wiki/Week_number#Week_numbering
I find MySQL's week number a bit strange actually, because no week numbering scheme I know would return week 53 for January 1st, 1987 (but that doesn't mean very much though...)