Working on a ASP.NET MVC web application project that uses Entity Framework 6.0 and SQL Server 2014 database.
START_TIME column is defined as time(7). When the View posts back a value like 08:00 am the Controller sends back this error.
"The value '08:00 am' is not valid for START_TIME."
Isn't the hh:mm tt format supported as described in the Supported String Literal formats for time section?
Omitting tt in the format works. But I need to have that. I don't want to use military time if at all possible.
EDIT (adding model's properties screenshot):
Related
I'm working on a project that was used only in one country but now is in using in several countries.
So I'm working in some DateTime issues, as you can image.
I'm using angular js for my frontend, python for my backend and Postgres as my database in this project.
To avoid any problem with DateTime and try to make more easy to work with the timezones I'm saving the DateTime in the database as UTC.
from DateTime import DateTime
# inside a class of my entity
self.start_date = datetime.utcnow()
This is working fine, the problem is when I try to convert the date back.
For example.
If my application is running in a country with GMT -1, when the user
asks to save the entity and it's 2016-07-13 15:00:00, in the database
(using the UTC now()) the DateTime will become 2016-07-13 16:00:00.
But when I try to get back the value I have two scenarios:
If I don't do anything, I'll receive the DateTime like it's on the database, "2016-07-13 14:00:00"
If I try to convert to the local timezone, I'm getting like 2016-07-13 17:00:00. The time was increased by 1 and not decrease was I expected.
I'm trying to use the momentjs library to work with dates, but nothing seems to work.
I'm wondering if what I supposed to do is get the GMT, like (-01:00) then do some math with the DateTime that comes from the database, like sub or sum the GMT hours difference.
Solution:
My solution for this was, store everything as UTC in my database.
Retrieve the datetime as UTC and covert to browsers timezone using momentjs library.
Doing like this.
moment.tz(moment.utc(datetime), moment.tz.guess());
I have an issue with getting dates back in the right timezone.
Firs at all in the local machine, everything works fine but not in the server: the server is hosted in USA and the clients mostly are in Australia.
So a date is sent from angular app("12/23/2015 11:00:00 AM") to the server, the server store a date as utc in the database, until this point everything is working(I checked and the date is stored in the right utc)
book.StartDateTime = TimeZoneInfo.ConvertTimeToUtc(DateTime.SpecifyKind(book.StartDateTime.Value, DateTimeKind.Unspecified), ToolsHelper.OlsonTimeZoneToTimeZoneInfo(locationDetails.TimeZone)); // book.CreatedDate.Value.ToUniversalTime();
The issue is:
When a client request some dates stored in the database. The date stored in the database is return back to the client like this:
bookview.StartDateTime = TimeZoneInfo.ConvertTimeFromUtc(DateTime.SpecifyKind(bookli.StartDateTime.Value, DateTimeKind.Utc), ToolsHelper.OlsonTimeZoneToTimeZoneInfo(deCompany.TimeZone));
I checked and at this point the date is "12/23/2015 11:00:00 AM" -> the conversion is right in the server(in the server side I put a log),
But in the angular is shown as "12/23/2015 10:00:00 PM"
So apparently the issue is when the date is transferred by the api to the client, maybe when is converted to JSON
I have tried different ways nothing work, I have removed "DateTime.SpecifyKind", I convert the date to string then back to datetime format and nothing seems to work.
What could I do?
A few things:
Your example is not complete, so I can only speculate on some areas. It would be better to show both sides, including how you load and parse the data in Angular, and what the data looks like over the wire.
You shouldn't be sending dates back and forth in a locale-specific format like "12/23/2015 11:00:00 AM". You might use those in your UI, but they're not appropriate over the wire (in your JSON). Instead, you should be using ISO8601/RFC3339, such as "2015-12-23T11:00:00Z". (You probably are already doing this if you're using WebAPI.)
A DateTime object when serialized to ISO8601 format is coupled with the associated DateTimeKind in the Kind property.
If the Kind is Utc, then the ISO8601 string will end with a Z.
If the Kind is Local, then the ISO8601 string will end with the machine-local offset for that timestamp, such as -08:00.
If the Kind is Unspecified, then the ISO8601 string will not have either Z or offset - which means that it cannot unambiguously represent a specific moment in time.
This is ultimately the cause of the error. You're converting the DateTime to another time zone, which leaves it with Unspecified kind, which then gets serialized without an offset - so on the client side that gets interpreted (probably) in the local time zone of the browser.
A better approach is to use DateTimeOffset instead of DateTime. Then you don't have to worry about Kind, and the offset is always present. If you change your bookview.StartDateTime to a DateTimeOffset type, you can do something like this to fix the problem:
DateTimeOffset dto = new DateTimeOffset(bookli.StartDateTime.Value, TimeSpan.Zero);
bookView.StartDTO = TimeZoneInfo.ConvertTime(dto, ToolsHelper.OlsonTimeZoneToTimeZoneInfo(deCompany.TimeZone));
That will ensure that the offset gets persisted in the data.
On the client side, pay careful attention to how the ISO string gets parsed. if it's loaded into a Date object, then it will indeed be converted to the client's time zone. Instead, you might take a look at moment.js for client-side time formatting. In particular, use moment.parseZone to keep the value in the same offset that it was presented. For example:
var s = moment.parseZone("2015-12-31T11:00:00+00:00").format("L LT"); // "12/31/2015 11:00 AM"
In commented code, you also showed a call to DateTime.ToUniversalTime - be very careful with that. If the source kind is Unspecified, it is treated as Local. Therefore, the local time zone of the computer is reflected in the converted value. It's better to avoid ToUniversalTime and ToLocalTime entirely. Use only the conversion methods on TimeZoneInfo.
ToolsHelper.OlsonTimeZoneToTimeZoneInfo isn't something we know about either. But I'll assume it does a CLDR mapping similar to this one. However, if you're working with Olson time zones anyway, the better approach would be to not use TimeZoneInfo at all. Instead, use Noda Time, with it's native support for tzdb time zones.
I am having trouble with date submissions to a database. When date and time are both needed, I parse the values from the database as a timestamp, which gives me the value of the date and time in milliseconds since 1970. Using the AngularJS date filter, I am able to display the value in a user-friendly way.
$filter('date')(1380292078000, 'MM/dd/yyyy hh:mm a'); => 09/27/2013 10:27 AM
But this format as a timestamp when I send the value back to the database, my code throws an error. The database wants the date to be displayed in a different format.
java.lang.IllegalArgumentException: Timestamp format must be yyyy-mm-dd hh:mm:ss
So I add a second filter to convert the value date representation of the millisecond count (the user might have changed the value), but I am just getting a clone of the first date representation.
$filter('date')('09/27/2013 10:27 AM', 'yyyy-mm-dd hh:mm:ss') => 09/27/2013 10:27 AM
Here is a link to the fiddle I wrote to test this. Are we not able to stack filter conversions on top of each other? I had a thought to convert the first conversion result into milliseconds to use as a source for the second conversion, but I didn't see a method to accomplish this in the date documentation. If that would be the only solution, though, I am sure I could whip something up. Because Java has mostly deprecated functions to work with dates, I feel it would be simpler to handle this on the Javascript/AngularJS side.
The date filter will only work with a JSON date string (see source).
You can get around your problem by converting to a date object:
$scope.date2 = $filter('date')(new Date($scope.date), 'yyyy-MM-dd hh:mm:ss')
See updated fiddle
However... You should be validating and formatting this input on the server side. You can't trust data coming from a javascript application to be in the correct or expected format. I'd recommend just posting back $scope.date and allowing the server to format in your database format. By doing the yyyy-MM-dd hh:mm:ss formatting on the client-side, you're tightly coupling your user interface to database implementation and that's generally considered a bad idea.
new Date(moment().year(), moment().month(), moment().day(), vm.newHearing().HearingTime().split(":")[0], vm.newHearing().HearingTime().split(":")[1]).toLocaleString()
The client side value for a date column is 11/5/2013 10:15:00 AM. The time is selected from HTML5 time input control.
When I check in database after saving the entity, it shows me incorrect time value:
11/5/2013 3:15:00 PM
It appears that you are using moment.js, which is fine except you aren't using it properly
Try this instead:
moment(vm.newHearing().HearingTime(), "HH:mm").toISOString()
That will pass the selected time, on the current day, from the user's local time zone, converted to UTC time and in ISO format.
Now that might not be exactly what you want to do. Depending on your requirements, you might instead want this:
moment.utc(vm.newHearing().HearingTime(), "HH:mm").toISOString()
Which is almost the same thing except that it assumes the input time is already in UTC.
Or you might want this:
moment(vm.newHearing().HearingTime(), "HH:mm").format("YYYY-MM-DDTHH:mm:ss")
This one doesn't try to convert to UTC at all.
For all choices, I emit the date string in ISO8601 format. Since you are sending it back to the server, this is the best choice. When you used toLocaleString, that generates a format that is appropriat for display only.
I am firing a insert query in 'dd/mm/yyyy' format but it is storing date into MM/DD/YYYY format.
I just want to know why it is happening?
This is insert query i am using.
insert into txnblackout(endtime,idtxn,blackoutflag,starttime,startdate,typeuser,id_entity,idsequence,idapp,enddate)
values('83520','LGN','D','7920',TO_DATE('30/12/2012','dd/mm/yyyy'),'ECU','B001','4','A1',TO_DATE('30/12/2012','dd/mm/yyyy'))
If you don't want to change the Windows date format (as suggested by Colin 't Hart), you can
use an explicit to_char() date format in your query (as suggested by Robert Hanson)
set your client NLS settings
configure your client (since you seem to be using PL/SQL developer):
Tools -> Preferences -> NLS options -> Date -> check user defined + enter your format
Personally, I'd set the client NLS settings.
This is a front-end issue: it's displaying the dates in that format. Because they are date fields, the dates really do represent the dates that you inserted.
I note in the bottom right hand corner of your screenshot that the date there is displayed in MM/DD/YYYY order. Change this setting in Windows and it will more than likely display correctly in your front-end tool.
The important bit can be gleamed by your insert, which includes "TO_DATE('30/12/2012','dd/mm/yyyy')". This is converting the string '30/12/2012' to an internal date object format that is specific to the DB. You can't control the underlying storage format. What you can control however is how that internal date object is converted back to a string by using date formatting functions when you call select.
select to_char(some_date, 'dd/mm/yyyy') my_date from some_table;
In the visual interface you referenced it is simply showing the default date to string conversion.