We Keep Coding

Cross platform DateTimeOffset conversion to CST Time Zone

I've written the following code to convert the DateTimeOffset to CST DateTime
var bookingDateInCst = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(itemRequest.BookingDate, "Central Standard Time");
This works on my local machine, but when I deployed it on PCF cloud environment I get the following error
"The time zone ID 'Central Standard Time' was not found on the local computer."
How to fix it?

I've used TZConvert utility, by reading this block
https://devblogs.microsoft.com/dotnet/cross-platform-time-zones-with-net-core/
It helped me fix the issue using following code:
var cstTimeZoneInfo = TZConvert.GetTimeZoneInfo("Central Standard Time");
var bookingDateInCst =TimeZoneInfo.ConvertTimeFromUtc(itemRequest.BookingDate.UtcDateTime, cstTimeZoneInfo);

The time zone ID 'CST' was not found on the local computer

I am having problem in creating a shipment in MAC Operating System. In windows operating system the website works fine. Any Help would be appreciated
Thanks.
Code:
createOrUpdateShipment: function (shipmentHeader) {
----------
var tzm= (/\((.*)\)/.exec(new Date().toString())[1]);
return $http.post('/shipment/CreateOrUpdateShipment?tzm='+tzm, shipmentHeader)
},
And in the Controller
public ActionResult CreateOrUpdateShipment(ShipmentInfo shipmentInfo, string tzm)
TimeZoneInfo tzi = TimeZoneInfo.FindSystemTimeZoneById(tzm);
shipmentInfo.ServiceInfo.READYDATETYPE = TimeZoneInfo.ConvertTime(shipmentInfo.ServiceInfo.READYDATETYPE,tzi);
Below Error I am getting when I try to create the shipment using MAC Operating System
Getting error time zone not found exception. The time zone ID 'CST' was not found

Time zones in .NET are identified by their full names, not their abbreviations. You are making a call to FindSystemTimeZoneById. This API would expect "Central Standard Time", not "CST".
I would guess that your Mac client is sending tzm=CST and your Windows client is sending tzm=Central+Standard+Time. Your server only works when the client spells it out.

Inconsistent DateTime conversion behaviour in .NET Web Service

Problem
I've a Windows app syncs with the Server using SharePoint hosted Web Services.
When the app syncs to the server using LAN (goes through an internal Proxy server) all the DateTime formats are in dd/MM/yyyy format (which is how it is intended to be)
However, when the app syncs over 4G,all DateTime formats are in MM/dd/yyyy format.
This happens for all data inbound and outbound.
Server
Windows Server 2012 with SharePoint 2013 hosting SOAP services
Region: Singapore
Format: English (Singapore)
Client
Windows 10 tablet app
Region: Singapore
Format: English (Singapore)
Other information:
1. It is the same tablet being used on both WiFi and 4G, so we can rule
out 2 tablets having different regional settings.
2. I've verified that the Windows 10 app passes the formats correctly and it is the server that behaves differently over WiFi and 4G.
3. I beleive that the issue is caused by .NET itself and not because of SharePoint. However, I don't want to rule it out as I'm not sure of the actual cause. Please comment if you require any further information if you feel that it is caused because of SharePoint
Snippets:
I've skipped the using statements and SPWeb statements in the snippet to keep it simple. And the LastModifiedTime field in the SPList of type DateTime and not single line text.
Model
public class Record
{
public string ID {get; set}
public string ModifiedDateTime {get; set;} //Don't ask why it is not a DateTime object. It was too late by the time I took over
}
Web Service
public class WebService : IWebService
{
public List<Record> GetUpdates(string lastModifiedTime)
{
SPQuery query= QueryBuilder.GetUpdateQuery(lastModifiedDateTime);
SPList spRecordList = spWeb.Lists["Record"];
SPListItemCollection results = spRecordList.GetItems(query);
List<Record> records = new List<Record>();
foreach(SPListItem spRecord in results)
{
Record record = new Record();
record.ID = spRecord.ID.ToString();
record.ModifiedDateTime = Convert.ToString(spRecord["LastModifiedTime"]);
//1 June 2015 would return as 01/06/2015 in WiFi but 06/01/2015 on 4G
records.Add(record);
}
return records;
}
public Record CreateOrUpdateRecord(Record record)
{
SPListItem spRecord = null;
SPList spRecordList = spWeb.Lists["Record"];
if(string.IsNullOrEmpty(record.ID))
{
spRecord = spRecordList.AddItem();
record.ID = spRecord.ID.ToString();
}
else
{
spRecord = spRecordList.GetItemByID(record.ID);
}
DateTime modified = Convert.ToDateTime(record.Modified);
spRecord["LastModifiedTime"] = modified;
/*
Say ModifiedDateTime is 1 June 2015.
Then on WiFi, modified = 01/06/2015
On 4G, modified = 06/01/2015
*/
return record;
}
}
Now, I've fixed the problem by using format strings when converting between string and DateTime and vice-versa. So more or less, I've got it working for now.
So my question here is, what is the reason behind this behaviour? If possible, please cite links to documentation or references to any other sources that explain this behaviour
Is it possible that the server infers the culture info from the request header? I've always thought that the DateTime.Parse()/Convert.ToDateTime() always got the defaults from the regional settings of the machine it runs on.

First of all, a DateTime does not have any implicit format. It just have date and time values. Format concept only applies when you get it textual (string) representation. I strongly suggest to change this data type from string to DateTime if you can that returns by web service.
I've verified that the Windows 10 app passes the formats correctly and
it is the server that behaves differently over WiFi and 4G
There is no such a thing. Parsing string to DateTime or vice versa does not depends on how you connected to internet. It is all about culture settings.
Since you use it as;
DateTime modified = Convert.ToDateTime(record.Modified);
This code will use CurrentCulture settings by default where it's located. Since you said;
It is the same tablet being used on both WiFi and 4G, so we can rule
out 2 tablets having different regional settings
One regional settings parse your string as a 6 January and the other settings parse your string as 1 June. That's too normal. Looks like one setting uses dd/MM/yyyy format and the other one uses MM/dd/yyyy.
As a solution, you can use DateTime.ParseExact method to specify exact culture that matches with your string. Or you can equalize regional settings on both tablet.
For example;
DateTime dt = DateTime.ParseExact("01/06/2015", "dd/MM/yyyy", CultureInfo.InvariantCulture);
will parse as 1 June 2015 but
DateTime dt = DateTime.ParseExact("01/06/2015", "MM/dd/yyyy", CultureInfo.InvariantCulture);
will parse as 6 January 2015.

Inconsistencies in DateTime between local machine and Azure

I have an app hosted in an Azure Website. When using the hosted application, the DateTimes are displayed and saved properly. When I run the application locally, and pull the data from the Azure SQL database, I get very weird results. Every datetime seems to be 6 hours off.
If I'm on my local box and I pull data from the server, all datetimes are displayed as actual+6 hours.
If I then, from local box, post something to Azure SQL, the time gets saved as actual-6hrs.
An example of the reads/writes I'm talking about:
Write:
var chatMessage = new ChatMessage() {
DatePosted = DateTime.Now
};
db.ChatMessages.Add(chatMessage);
Read:
// get chatMessage from db
messageVm.DateIndicator = DateUtilities.GetFriendlyDate(chatMessage.DatePosted);
// GetFriendlyDate is:
public static string GetFriendlyDate(DateTime? postDate) {
if (postDate == null) {
return null;
}
string stringy = string.Empty;
TimeSpan diff = DateTime.Now.Subtract((DateTime) postDate);
double days = diff.Days;
double hours = diff.Hours + days * 24;
double minutes = diff.Minutes + hours * 60;
if (minutes <= 1) {
return "Just Now";
}
// etc
}
So in the above Read - if I'm running the app locally and accessing Azure SQL, content posted 5 hours ago is being displayed as posted "Just Now", and if I save a new message, the hosted application displays the time as 6 hours ago (when it should be "just now").
Splitting the logic (local) from the db (azure) is obviously the cause of this - but is this an indication that I'm not handling DateTimes properly? If so, what am I doing wrong?

You're in a different time zone. Use DateTime in UTC, or better yet avoid all the oddities of that and use DateTimeOffset.
Unlike .NET's DateTime type, databases don't have a "Kind" that indicates if they're a local or UTC date. This makes them really easy to use inconsistently and not even realize it. DateTimeOffset stores an offset from UTC, so it does not have the same problem.

Try using DateTime.UtcNow rather than DateTime.Now

C# P/Invoke Attribute

New to C# Compact edition 6.5. I am trying to set the datetime on a file which seems to be off by 5 hours from the actual system time. I am doing only this to create the file:
FileStream fs= File.Create(name);
Just doing this the Created date is 5 hours ahead...if I try and set the CreationTime I get a compile error saying the Attribute is Readonly, seriously?
FileInfo fi = new FileInfo(name);
fi.CreationTime = date;
So my question is since I am new to C# how do you get access to a "readonly" Attribute in the CE framework? I see mentioning of P/Invoke but seems to work on methods only and not attributes. Anyone can given a quick demo on how to do this?
I've tried this solution and still get the file writing UTC even though I send it the current local time

I just ran this:
[MTAThread]
static void Main()
{
var name = "\\foo.txt";
var info = new FileInfo(name);
using (info.Create()) { }
info.Refresh();
var createTime = info.CreationTime;
var now = DateTime.Now;
var delta = now - createTime;
Debug.WriteLine(delta.ToString());
}
And got this output:
00:00:00.0140000
Which seems to be correct to me.

You can't modify the CreationTime of a file. It's set once and only once when the file is created. If you're willing to use P/Invoke to set the time, you can check out this similar question - c# - Change file LastWriteDate in Compact Framework
Instead of hacking the problem, though, you should fix the root cause. If there's an issue with the creation time of the file, I would consider checking your system's time settings (including timezone).