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);

Get users current location

Have been working on WPF application where users current location had to be identified (it is configurable in settings = no anonymous tracking for private data). Several solutions has been tested.
Alternative number 1 - works fine on different computers, also with VPN is on. Location is tracked based on IP address and everything seems to be good. However downside of this is that it uses external sources, like third party websites for getting IP address and then read that IP address to get the location.
public string GetPublicIP()
{
String direction = string.Empty;
WebRequest request = WebRequest.Create("http://website/");
using (WebResponse response = request.GetResponse())
using (StreamReader stream = new StreamReader(response.GetResponseStream()))
{
direction = stream.ReadToEnd();
}
//Search for the ip in the html
// code here
return direction;
}
Alternative number 2 - C# Geolocator class. This works fine with additional JSON file with geolocation coordinates and location data. However on corporate computer PositionChanged event is not firing for some reason. Not sure is it blocked somehow. No exceptions, but location is not recognized due to event is not firing. On my personal computer same solution works fine (same Windows version - Windows 10). Geolocator.ReportInterval = 1000; is also not force firing event every 1 second.
private void RunGeoTracker()
{
if (Geolocator == null)
{
Geolocator = new Geolocator();
Geolocator.DesiredAccuracy = PositionAccuracy.High;
Geolocator.MovementThreshold = 100; // The units are meters.
Geolocator.ReportInterval = 1000;
Geolocator.PositionChanged += this.PositionChanged;
}
}
private async void PositionChanged(Geolocator sender, PositionChangedEventArgs args)
{
await Dispatcher.InvokeAsync(() =>
{
// code here
}
}
Are there are any alternatives, preferably without using any REST API or websites. Preferably using JSON or database for getting location data. I heard there is some PowerShell solution? Can't find examples. I mean basically Latitude and Longitude are needed. All the rest can be already achieved.

The Windows-native Geolocator API is limited by the wide variety of states a Windows laptop can be in - airplane mode, location settings disabled in common Windows settings, disabled in application-specific settings, or merely that no data providers are available to the OS (GPS satellites, WiFi triangulation, internet connectivity, OEM hardware and firmware etc.). So, any strategy to use OS-specific Geolocator API is contingent on your application (a) needing high-accuracy GPS fix, (b) involving mobility - e.g a worker driving with their open laptop in a car, or (c) ability to guide the user through UX that helps them get a location fix.
That said, do check if your Geolocator object initialization is done correctly via the steps in Microsoft's documentation - they matter!
IP geolocation has its limitations around VPN users, but it has much fewer ways of failing once you ship the software to real-world PCs and laptops. The following REST API for example will not only auto-detect the device's public IP but also respond with the approximate city-level location, including coarse latitude+longitude.
https://ep.api.getfastah.com/whereis/v1/json/auto?fastah-key=<trial_key>
The JSON response may look as follows, where the public IP is echoed back to your client application:
{
"ip": "146.75.209.1",
"isEuropeanUnion": false,
"locationData": {
"countryName": "Australia",
"countryCode": "AU",
"cityName": "Canberra",
"cityGeonamesId": 2172517,
"lat": -35.28,
"lng": 149.13,
"tz": "Australia/Sydney",
"continentCode": "OC"
}
}
The trick is to use IP location APIs that constantly update themselves as the internet and mobile landscape evolve fast.
Disclaimer: I am the developer of the above Fastah API service, so I may be a bit biased here :)

Azure culture-specific month/day formatting different than localhost

I'm running into a very strange issue where the "month/day" standard date format as specified on https://msdn.microsoft.com/en-us/library/az4se3k1(v=vs.110).aspx is rendering differently on my local machine than it is on my azure cloud services and websites.
The culture in this case that is rendering differently is "en-AU". For the date of 2017-05-04 it should render as 4 May and on my local machine it does exactly that. On our website (azure cloud service) and our API (azure website) it renders as May 4. The strange part is that if I use the "short date pattern" it renders as 04/05/2017 on both azure/local. So this seems to be specific only to the "month/day" pattern.
I've tried setting
var culture = new CultureInfo("en-AU");
Thread.CurrentThread.CurrentCulture = culture;
Thread.CurrentThread.CurrentUICulture = culture;
and the formatting code is
string.Format(new CultureInfo("en-AU"), "Until {0:M} {0:yyyy}", endDate);
I'm wondering if its possible that the version of some culture definition is different in Azure than it is on my local machine? To my knowledge they are both running .net 4.5. I've added log statements in the code so I can confirm that the culture is set correctly on the line that the code runs, but for some reason, it is just outputting a different value in Azure than it does locally.

I have used both "en-AU" and "en-ZA" culture in both local and Azure environments.Unfortunately,I did not face the issue that you have mentioned in your question in both environments.
It seems the date format that you are getting is US format which might be due to the fact that azure data center that you are using to host your application is based in USA and your date is formatted to that culture.Anyway,give a try to format the date like :
var currentCulture = new CultureInfo("en-AU");
var formattedDate = DateTime.Now.ToString("G",currentCulture);
For the South African culture,try the following:
var currentCulture = new CultureInfo("en-ZA");
var formattedCurrency = currency.ToString("C", currentCulture);
//currency = 100000 then formattedCurrency => R 100 000,00
Good luck ..!!!

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.

Get PC TimeZone on C#

Im currently developing on asp - c# as a backend code. I want to get the current timezone that was set on the PC.
The below code are still identifying what is the correct timezone of my current area (+8GMT) even though I already changed my PC timezone settings into another timezone.
What I want is to get the timezone offset specified on the PC date settings. Can anyone help me on this. Below is my code so far.
public TimeSpan currentOffset;
public DateTime utc;
public DateTime local;
this.utc = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.Now, TimeZoneInfo.Utc.Id);
this.local = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.Now, TimeZoneInfo.Local.Id);
this.currentOffset = this.local.Subtract(this.utc);

In addition to David Haney's answer.
TimeZoneInfo is caching data after first call so any changes in PC settings will not affect your application if it is already running.
You should call method:
TimeZoneInfo.ClearCachedData();
to refresh this cache.
So this one will work in your case:
TimeZoneInfo.ClearCachedData();
var offsetTimespan = DateTimeOffset.Now.Offset;
var offsetInHours = offsetTimespan.TotalHours;

You're making your life harder than it needs to be. :)
Use DateTimeOffset: http://msdn.microsoft.com/en-us/library/system.datetimeoffset.now%28v=vs.110%29.aspx
var now = DateTimeOffset.Now;
This will include the time zone offset information as well.