We Keep Coding

Google Drive API watch channel is only 24h

I am using the v3 api drive file watch api. I just want to subscribe to the changes made in specific folders. I was able to establish the watch channel. However, the expiration date I receive is only 24h even when I set it manually to 7 days.
var expirationWatchTime = DateTimeOffset.UtcNow.AddDays(7);
var channel = DriveService.Files.Watch(
new Channel
{
Address = _googleConfiguration.Value.WebHookUrl,
Type = "web_hook",
Id = projectDocumentFolderId.ToString(),
Expiration = expirationWatchTime.ToUnixTimeMilliseconds()
},
missingFolder.Id).Execute();

I'm checking the official documentation and it seems that subscribing to file resources changes will have a maximum expiration date of 24 hours. I'll quote the specific note:
Note: For the Drive API, the maximum expiration time is 86400 seconds (1 day) after the current time for File resources and 604800 seconds (1 week) for Changes. If you don’t set the expiration property in your request, the expiration time defaults to 3600 seconds after the current time.
There is this thread that it as well provides the same answer.

c# SMO Backup - how to use ExpirationDate?

I followed roughly this example to backup a database with Microsofts SMO API and the code crashed with an exception telling invalid parameter ExpirationDate. I checked the documentation which does not contain details on how to set the parameter and my intuition told me it should be in the future, right? I was curious and tested some values:
DateTime.Today.AddDays(10) -> InvalidDataException
DateTime.Today.AddDays(-10) -> works fine
DateTime.Today.AddDays(-5) -> works fine
DateTime.Today.AddDays(-4) -> works fine
DateTime.Today.AddDays(-3) -> InvalidDataException
DateTime.Today.AddDays(-1) -> InvalidDataException
DateTime.Today.AddDays(100) -> InvalidDataException
DateTime.Today.AddDays(500) -> InvalidDataException
DateTime.Today.AddDays(1000) -> works fine
Reading this 5 year-old post it could be that the internal parameter is actually not of the type DateTime? But then it would be a bug, right?

These errors are likely the result of the locale of where the Backup.ExpirationDate property is being set from. Depending on the culture this is being executed in, the DateTime.AddDays method may increment the month instead of the day as expected, leading to the inconsistent results you saw. Of the values that you tested only the negative ones should cause errors, as the range of days for a backup expiration date is 0 - 99999, with 0 indicating that the backup will never expire as stated in the documentation. Try using the CultureInfo class to define a new locale then set the expiration date. This will require a reference to the System.Globalization namespace. Running the following code gave me no errors in setting the expiration date in a backup operation using the US (en-US) culture. Just make sure that the date in the culture you convert this to matches the date you expect it to in your timezone.
using System.Globalization;
string folderPath = #"C:\YourFolder\";
Server serv = new Server(#"YourServer");
Backup bkup = new Backup();
bkup.Database = "YourDatabase";
string bkupFilePath = folderPath + bkup.Database.ToString() + ".bak";
bkup.Action = BackupActionType.Database;
bkup.Devices.AddDevice(bkupFilePath, DeviceType.File);
bkup.BackupSetName = "YourDatabase Full Backup";
bkup.BackupSetDescription = "Full backup of YourDatabase";
DateTime today = DateTime.Now;
//define current date representation with en-US culture
string newLocale = today.ToString(new CultureInfo("en-US"));
//set Backup.ExpirationDate to use new culture
bkup.ExpirationDate = Convert.ToDateTime(newLocale);
bkup.ExpirationDate.AddDays(10);
bkup.ExpirationDate.AddDays(100);
bkup.ExpirationDate.AddDays(500);
bkup.ExpirationDate.AddDays(1000);
bkup.SqlBackup(serv);

edit I am super confused. I thought this solved my issue:
My issue was that I called backup.ExpirationDate.AddDays(X) without assigning it to anything. Therefore, the software was basically using "DateTime.Now".
Solution:
backup.ExpirationDate = backup.ExpirationDate.AddDays(X);
But it didn't completely. I still get the exception if I do this:
backup.ExpirationDate = backup.ExpirationDate.AddDays(1);
No idea why this code is wrong.

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.

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