ISO 8601 recommends the following format for a date and time:
2014-12-29T16:11:20+00:00
I'm rather fond of this format since it allows for lexical ordering. But there is a small problem: some file systems don't allow colons in file names (at least not normally). ISO 8601 does allow for omitting the colons, but I would rather have some symbol there than have the numbers run together:
2014-12-29T161120+0000
Does ISO 8601 allow for a symbol other than colons? I couldn't find any indication that it does. If not, is there another well recognized symbol I could use? (Perhaps another standard proposes such a symbol?)
There is none.
ISO 8601 only allows for a colon (:) for separating time components in the extended format:
The basic format is [hh][mm][ss] and the extended format is [hh]:[mm]:[ss].
There is no provision for an alternate extended format.
There's no other provision and you cannot have a complete datetime expresion with the first half in extended and the last one in basic formats; they must have the same formats.
A workaround, and i emphazise in workaround, is to split the string with something else, e.g., a period or underscore, that separates two valid expresions, the date in extended format and the time in basic format: e.g., myfilename_2020-12-13.T0006Z_otherNotes.ext or myfilename_2020-12-13_T0006Z_otherNotes.ext.
You must be clear with other parts involved in the usage of such files - mainly speaking about machine ones - in that it is not a complete datetime expresion, but 2 valid ones each one in different formats - extended, then basic - separated by an agreed and unambiguous character (i mentioned a period/underscore instead of a dash/hyphen specifically for this reason).
The obvious downsides of this approach are: the time part is harder to read and some other people could believe you badly implemented the ISO or you have poor understanding of it, when not.
The good sides... it works in Windows, it organizes the elements in the filesystem in the right order, despite the OS, it follows the ISO standards (in a special way) and it is compatible with machines (from scripts to AIs and everything in the middle).
It is a workaround. I repeat.
As a final note, i really wonder why the people doing ISO 8601-2019 didn't consider the problem that is using ISO in filenames or if they're totally unaware of it.
For combined date and time representations you must use basic format for both date and time or extended format for both date and time representations to comply with ISO 8601.
Examples of ISO 8601 compliant date and time representations:
2020-12-03T15:05:57+00:00 (extended)
2020-12-03T15:05:57Z (extended)
20201203T150557Z (basic)
For maximum compatibility with various operating systems file naming requirements and ISO 8601 compliance I think the last example or something similar should work.
Reference: https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
Related
In postgres when i do cast(varchar_col as timestamp) how do i know which formats (ie yyyymmdd, yyyy-mm-dd...etc) are supported?
Not great research on your end, because it's right there in the Postgres 8.4 docs in the section of the eponymous name:
https://www.postgresql.org/docs/8.4/datatype-datetime.html
Valid input for the time stamp types consists of the concatenation of a date and a time, followed by an optional time zone, followed by an optional AD or BC. (Alternatively, AD/BC can appear before the time zone, but this is not the preferred ordering.)
So, you need to combine all input format entries from the "Date Input" table and from the "Time Input" table, which are too many to list sensibly in an answer. Makes no sense either – that's what official documentation is for.
For a more comprehensive documentation on how dates and times are parsed from strings, that's officially documented as well:
https://www.postgresql.org/docs/8.4/datetime-input-rules.html
In Oracle DATE output format is set using NLS_DATE_FORMAT but in PostgreSQL it is not flexible to set the DATE output format like Oracle.
In PostgreSQL DATE output format can be set using DateStyle but DateStyle values are limited so user can not change the DATE output format flexibly.
To overcome this problem we can use to_char().
Is there any other way to set DateStyle or Create custom DateStyle output format?
You've already shown the options:
to_char; or
DateStyle, within the limits it allows.
Client applications are supposed to format dates. PostgreSQL just supplies a standard date in an easily parsed format for client drivers to read. In fact, if you use the binary protocol it just sends the date as a bigint.
If you feel strongly about this you could propose a patch to the pgsql-hackers mailing list adding the feature you desire. You will need to be willing to learn enough PostgreSQL back-end coding to implement this yourself, or to pay someone else to do it. I don't particularly see why DateStyle couldn't be extended to accept a format string, but I don't think anybody's cared enough to do the work (and patch all the client drivers to support it).
I am currently starting from scratch choosing a database to store data collected from a suite of web forms. Humans will be filling out these forms, and as they're susceptible to using international characters, especially those humans named José and François and أسامة and 布鲁斯, I wanted to start with a modern database platform that accepts all types (so to speak), without conversion.
Q: Does a databases exist, from the start, that accepts a wide diversity of the characters found in modern typefaces? If so, what are the drawbacks to a database that doesn't need to convert as much data in order to store that data?
// Anticipating two answers that I'm not looking for:
I found many answers to how someone could CONVERT (or encode) a special character, like é or a copyright symbol © into database-legal character set like © (for ©) so that a database can then accept it. This requires a conversion/translation layer to shuttle data into and out of the database. I know that has to happen on a level like the letter z is reducible to 1's and 0's, but I'm really talking about finding a human-readable database, one that doesn't need to translate.
I also see suggestions that people change the character encoding of their current database to one that accepts a wider range of characters. This is a good solution for someone who is carrying over a legacy system and wants to make it relevant to the wider range of characters that early computers, and the early web, didn't anticipate. I'm not starting with a legacy system. I'm looking for some modern database options.
Yes, there are databases that support large character sets. How to accomplish this is different from one database to another. For example:
In MS SQL Server you can use the nchar, nvarchar and ntext data types to store Unicode (UCS-2) text.
In MySQL you can choose UTF-8 as encoding for a table, so that it will be able to store Unicode text.
For any database that you consider using, you should look for Unicode support to see if can handle large character sets.
Here is my problem. the date that i got from my database contains "12/31/2013". Based on this date, the format is mm/dd/yy. Now the question is how do i makes it that no matter what format of the date in the user's computer, they will always read the date "12/31/2013" as mm/dd/yy instead of example dd/mm/yy which when it reads it contains an error due to there is no 31 month. i try the split method on the date i receive from my database but i coudn't get it to confirm to the format that is independent from the user's computer
Is your date being stored in your database as an actual date format, or as a string?
Remember that DateTime.Parse by default, uses the current user's current system date/time formatting settings (so UK users are dd/MM/yyyy, but US users are MM/dd/yyyy). If you want uniform parsing then use DateTime.ParseExact and specify an exact parsing format string.
One rule of thumb that's useful to remember is that "if you're ever using String.Split, you're probably doing something wrong" (I'll make exceptions for quick-and-dirty by-design programs, but for parsing a Format-string, Regular-expression, or Finite state machine is more performant (less string allocations) and less brittle.
Back on-topic, if your database is storing objects as a date or datetime then don't use strings at all. Use the .GetDateString(int) method of IDataReader or typed field properties of EF classes.
How did you get a date from your database? Did you store the date as a string? If at all possible, consider keeping the date as a DateTime variable rather than a string. If not possible, look into the DateTime.TryParse method which supports internationalization and should be able to understand with the user's UI localization settings.
Its not clear if you want to read the same format from the database or display it on the screen (UI)
If its from the sql server, consider using convert <- follow this link
What is the general guidance on when you should use CAST versus CONVERT? Is there any performance issues related to choosing one versus the other? Is one closer to ANSI-SQL?
CONVERT is SQL Server specific, CAST is ANSI.
CONVERT is more flexible in that you can format dates etc. Other than that, they are pretty much the same. If you don't care about the extended features, use CAST.
EDIT:
As noted by #beruic and #C-F in the comments below, there is possible loss of precision when an implicit conversion is used (that is one where you use neither CAST nor CONVERT). For further information, see CAST and CONVERT and in particular this graphic: SQL Server Data Type Conversion Chart. With this extra information, the original advice still remains the same. Use CAST where possible.
Convert has a style parameter for date to string conversions.
http://msdn.microsoft.com/en-us/library/ms187928.aspx
To expand on the above answercopied by Shakti, I have actually been able to measure a performance difference between the two functions.
I was testing performance of variations of the solution to this question and found that the standard deviation and maximum runtimes were larger when using CAST.
*Times in milliseconds, rounded to nearest 1/300th of a second as per the precision of the DateTime type
CAST is standard SQL, but CONVERT is only for the dialect T-SQL. We have a small advantage for convert in the case of datetime.
With CAST, you indicate the expression and the target type; with CONVERT, there’s a third argument representing the style for the conversion, which is supported for some conversions, like between character strings and date and time values. For example, CONVERT(DATE, '1/2/2012', 101) converts the literal character string to DATE using style 101 representing the United States standard.
Something no one seems to have noted yet is readability. Having…
CONVERT(SomeType,
SomeReallyLongExpression
+ ThatMayEvenSpan
+ MultipleLines
)
…may be easier to understand than…
CAST(SomeReallyLongExpression
+ ThatMayEvenSpan
+ MultipleLines
AS SomeType
)
CAST uses ANSI standard. In case of portability, this will work on other platforms. CONVERT is specific to sql server. But is very strong function. You can specify different styles for dates
You should also not use CAST for getting the text of a hash algorithm. CAST(HASHBYTES('...') AS VARCHAR(32)) is not the same as CONVERT(VARCHAR(32), HASHBYTES('...'), 2). Without the last parameter, the result would be the same, but not a readable text. As far as I know, You cannot specify that last parameter in CAST.