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).
Related
I'm trying to INSERT date variable into my SQL server.
The input format I'm trying to insert is: dd-mm-yyyy
And my SQL server column (which defined as type DATE) expect mm-dd-yyyy.
My PC date format is dd-mm-yyyy.
The error msg:
Conversion failed when converting date and/or time from character string.
Questions:
Why is the expected format mm-dd-yyyy and not dd-mm-yyyy?
How can I make the INSERT command work with this or another date format?
Thanks.
The format that your PC uses for dates doesn't matter when passing literal string for dates, the language setting for the LOGIN you are using to connect to SQL Server does. As the value is being interpreted as MM-dd-yyyy this very likely means that your language setting is (American) ENGLISH.
If, therefore, you are the only person that uses that LOGIN you may well want to change the language of your LOGIN to be appropriate for yourself. Most of the European languages, including BRITISH English (because the British don't speak English Microsoft? 😒) use the format dd-MM-yyyy.
Really, however, what you should be doing is using an unambiguous date format, of which there are only 2 in SQL Server, regardless of the language setting and data type. Those 2 formats are yyyyMMdd and yyyy-MM-ddThh:mm:ss.nnnnnnn. If you are always using the newer date and time data types (so not datetime or smalldatetime), then yyyy-MM-dd( hh:mm:ss.nnnnnnn) is also unambiguous, however, as it's language specific for the older data type then I don't normally recommend it's use.
Storage wise, date and time data types don't have a format, so your column isn't "expected" a value in the format MM-dd-yyyy, as it doesn't retain the "format data" that the value was passed in. Again, the only reason why a value like 13-12-2020 is working is because your language setting, which uses mdy for date interpretation.
Two things really,
Firstly, you can control the expected date format for each connection. Before issuing the insert statement, do set dateformat dmy; or set dateformat mdy; as appropriate.
Secondly, it's always advisable to work with dates in the ISO format of YYYYMMDD, so if you insert the data '20210314' it will always be treated correctly.
I'm trying to write a schema for an ActiveRecord object.
I've decided to use iso8601 format throughout my application, including for external api requests.
Should the column be a string or datetime?
Is there any performance impact or distinction between the two?
Storing the date in the database as a date or datetime means you can use the date functions like comparing dates in the database. And it gives you the freedom to present the date in whichever format you choose, making it easy to do so if the formatting requirements change in the future, without having to touch the database.
Whereas storing the date in the database as a string removes all these advantages. You no longer can use database date functions. Plus, If you decide to use another format (maybe in a newer version of the API or for mobile apps... etc), you will need to parse the string back into a date/datetime object, which is not very appealing to do.
As a general good practice: the way you store data should be agnostic to the way you present it, when possible.
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
Is it possible to map a .Net DateTime to a TIMESTAMP with TIMEZONE type in Oracle using NHibernate? Looks like it's not readily available in "Hibernate"
If this is not available out of the box, can someone please direct to examples of how it may be achieved.
We were not able to find a proper mapping to this using NHb 3.1. However extended support for times (including timezone etc...) is available for SQL Server '07 onwards.
Our solution was to use a varchar field instead of timestamp and format the dates to include the timezone information. The consumer of this data was able to handle this change accordingly.
You could also convert them to UTC and store that.
Is there a way to change the default format of a date in Postgres?
Normally when I query a Postgres database, dates come out as yyyy-mm-dd hh:mm:ss+tz, like 2011-02-21 11:30:00-05.
But one particular program the dates come out yyyy-mm-dd hh:mm:ss.s, that is, there is no time zone and it shows tenths of a second.
Apparently something is changing the default date format, but I don't know what or where. I don't think it's a server-side configuration parameter, because I can access the same database with a different program and I get the format with the timezone.
I care because it appears to be ignoring my "set timezone" calls in addition to changing the format. All times come out EST.
Additional info:
If I write "select somedate from sometable" I get the "no timezone" format. But if I write "select to_char(somedate::timestamptz, 'yyyy-mm-dd hh24:mi:ss-tz')" then timezones work as I would expect.
This really sounds to me like something is setting all timestamps to implicitly be "to_char(date::timestamp, 'yyyy-mm-dd hh24:mi:ss.m')". But I can't find anything in the documentation about how I would do this if I wanted to, nor can I find anything in the code that appears to do this. Though as I don't know what to look for, that doesn't prove much.
Never mind :'(
I found my problem. I was thinking that I was looking directly at the string coming back from the database. But I was overlooking that it was reading it as a Timestamp and then converting the Timestamp to a string. This was buried inside a function called "getString", which is what threw me off. I was thinking it was ResultSet.getString, but it was really our own function with the same name. Oops. What idiot wrote that function?! Oh, it was me ...
Thanks to all who tried to help. I'll give you each an upvote for your trouble.
I believe the table columns are specified differently. Try these variants:
timestamp
timestamp(0) no millis
timestamptz with timezone
timestamptz(0) with timezone, no millis
With which client are you running the select statements? Formatting the output is the application's responsibility, so without knowing which application you use to display the data, it's hard to tell.
Assuming you are using psql, you can change the date format using the SET command:
http://www.postgresql.org/docs/current/static/sql-set.html
Which is essentially a way to change the configuration parameters. The ones that are responsible for formatting data are documented here:
http://www.postgresql.org/docs/current/static/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT
Daniel tells me to post my findings as an answer and accept it to close the question. Okay.
I found that the date format I was seeing that did not include a time zone was not what was coming directly from Postgres, but that there were a couple of function calls that I was missing that converted the incoming date to a java.util.Timestamp, and then from the java.util.Timestamp to a String. It was in this conversion from the Timestamp to the String that the time zone was defaulting to EST.
In my own humble defense, my mistake was not as dumb as it may sound. :-0 We had the execution of the query in a subclass that read the results into a List, which we do to allow modification of the query results before output. (In this case we are adding a coule of columns that are derived from the stored columns.) Then we have a set of functions that resemble the JDBC functions to pull the data out of the List, so a calling program can easily switch from processing a query directly to processing the List. When I was wrestling with the date format problem, it just didn't register on me that I wasn't looking at "real JDBC", but at "simulated JDBC" calls.