I'm working in native C (not C++ - I'd like for everything to stay in C as much as possible) on the Windows API and I'm having trouble with dealing with/comparing UTC strings. Basically I'm getting a date from a WMI call, which as I understand it is a UTC number returned as a DWORD, and I'd like to take a human-readable date-time (i.e. 11:11:11 08/04/2014) and compare that to the UTC date I already have so I can programmatically say which comes before the other.
However it doesn't look like the Windows API provides a good API, and I tried to do it using sscanf_s and mktime similar to the second answer here. This gave me a number that seem close but wasn't quite correct. i.e. both will be today's date within a few minutes has the most significant 3-4 digits the same but nothing else is close.
Is this a timezone/local time problem? Or am I just missing something?
Related
I would like to convert dates I receive from timezone 'Europe/Warsaw' to UTC. I have tried to find suitable libraries in C to create a Datastage routine. I did not find anything that would allow to flexibly change the source timezone keeping in mind the change from summer to winter time (daylight). Another way is to use a database function, e.g. in DB2, but currently I am trying to solve the problem without creating stored procedures. Anyone solved a similar problem?
I get the input date in the format 'YYYY-MM-DD HH:MI:SS',
Input Timezone = 'Europe/Warsaw',
Output Timezone = 'UTC'.
I would like to create a solution that would allow me to swap e.g. Input Zone, something passed by parameter e.g. 'Europe/London'. I cannot rely on the system time unfortunately.
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.
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 need to create a user defined Function that accepts a date input
and a date format input and results in a properly formatted date.
Ex: UDF('7/22', 'Internation')
OUTPUT: 22/7/2012
I need to implement all types of date formatting, or at least as much as possible. I think there should be at least 40 different types.
I've found solutions online that don't really work.
Does anyone have a function like this or can point me in the right direction. I'm pretty new to sql so writing this from scratch would take me until next week!
I am trying to query some data out of Home Bank using the data file it produces.
This is a transaction that appears in the file:
<ope date="734309" amount="-14.24" account="4" dst_account="0" paymode="0" flags="1" payee="239" category="2" wording="" info="" tags="" kxfer="0" />
I am interested in the date="734309". I've not seen this format before so don't know how to parse it.
The application is written in C if that is any help.
734309 / 365 = 2011.80548
So I guess it's something like "days since 1 January in the year 1". If you know the actual date that that number should represent, you can reconstruct the precise offset from there.
It's probably the result of the SQL TO_DAYS() function, which represents the number of days since the first day of 1 A.D. (I don't know whether TO_DAYS() is specific to MySQL or if it's a standard SQL function.)