I'm working with the Amazon API. I need to convert local time (EDT) to a DateTime that complies with the following documentation from Amazon:
You can specify the FulfillmentDate with or without time zone information:
2006-12-11T09:50:00 - local time zome applies
2006-12-11T09:50:00+02:00 - GMT time zone applies
For locales affected by Daylight Saving Time, adjust the information, if necessary.
Daylight Saving Time is not automatically taken into consideration.
I thought I needed to do something like shown in this SO thread, but apparently wrong, because when I upload the date using that method, Amazon shows it as a day before. I can confirm this by using this online converter tool.
For example:
My local time is "7/25/2012 00:00:00" (EDT).
Using above SO method, and formatted, it's now
"2012-07-25T01:00:00-04:00".
But it converts to the 24th, specifically "Tuesday, July 24, 2012 at
21:00:00".
Obviously I'm doing something wrong here - I'd appreciate if someone can enlighten me.
Thank you!
I would recommend using:
String xmlDateString = XmlConvert.ToString(DateTime.UtcNow,XmlDateTimeSerializationMode.Local);
Obviously Amazon converts your local time information back to UTC time (which is based on your input 4 hours back in time: Tuesday, July 24, 2012 at 21:00:00 and therefore correct).
Which result have you been expected?
I think I can introduce a "joda time" project written by Jon Skeet. You can refer to link pros and cons of joda time
Related
I'm currently using a third party DLL to run some of my programs.
It was working fine until recently I decided to move it to a new server running OS Windows Server 2016.
The library suddenly pops an error saying:
System.FormatException: Incorrect format. 'YYMMDDhhmmsstnnp'
I looked here https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings but couldn't see anything for t, nn and p.
Does anyone recognize the format above and knows what actually is t nn and p?
And how do I actually resolve the issue?
Thank you
Okay, after a little detective work (well, a search) I believe you're probably using the SMPPClient library, and that the error comes from this line. It's not trying to use that as a format string - it's only reporting it (unhelpfully, IMO) as the expected format of the string.
It's actually checking it using this regex:
"^[0-9][0-9][0-1][0-9][0-3][0-9][0-2][0-9][0-5][0-9][0-5][0-9][0-9][0-4][0-9][\\+\\-R]$"
The SMPP v5 specification explains the formatting:
‘YY’ last two digits of the year (00-99)
‘MM’ month (01-12)
‘DD’ day (01-31)
‘hh’ hour (00-23)
‘mm’ minute (00-59)
‘ss’ second (00-59)
‘t’ tenths of second (0-9)
‘nn’ Time difference in quarter hours between local time (as expressed in the first 13 octets) and UTC (Universal Time Constant) time (00-48).
‘p’:
“+” Local time is in quarter hours advanced in
relation to UTC time.
“-” Local time is in quarter hours retarded in
relation to UTC time.
This isn't something I'd expect a regular format string in .NET to handle.
I would suggest that your next steps should be:
Find out what value it was trying to parse (that could be tricky, I understand)
Work out where that value comes from (is it generated elsewhere in the code, possibly in your code, or is it data originating outside your system?)
Write a small program to just perform that regex on both the working machine and the problematic machine to work out whether the problem is that the regex behaviour has changed, or the data being parsed has changed
My guess is that some code somewhere is using regular DateTime formatting to create part of this string, and then tweaking it for the last part... and that on your new system, there are some locale changes that affect things. For example, even if you format with an explicit format, that will still use the calendar system of whatever culture it's using - if you're formatting to a non-Gregorian calendar accidentally, that could definitely affect things. (The common fix there is to explicitly use CultureInfo.InvariantCulture when formatting a machine-readable string.)
I'm not sure whether this is an SO question but still would like to know the answer.
Wikipedia says there are about 40 time zones, but when I invoke the TimeZoneInfo.GetSystemTimeZones() method in c# it returns a list of 101 elements.
Is the wiki article outdated (though it "was last modified on 26 April 2012 at 05:11") or are there any additional time zones?
There's no one answer - it depends on what time zone database you're interested in. Using TimeZoneInfo.GetSystemTimeZones will use the Windows time zones... if you use tzdb you're likely to see a lot more.
(The current Noda Time version returns 575 time zone IDs, for example, although that includes Etc/GMT+9, Etc/GMT+10 etc.)
I want to find out what will be the time in india when clock tick to 1Am mid night in any other country..
How i will find out that through any means
plz help me to find out this
this is to fire birthbay mails at 1AM midnight of that resp country...
.NET 3.5 added the class TimeZoneInfo which should be able to do want you want. Particularly, the TimeZoneInfo.ConvertTime(DateTime, TimeZoneInfo, TimeZoneInfo) method.
You can also use the TimeZoneInfo.GetSystemTimeZones() method to get the list of time zones that are registered in the system.
You might want to look at the method:
TimeZoneInfo.ConvertTime
SQL SERVER 2008 would have the DATETIMEOFFSET data type (which includes the time zone) plus functions like SWITCHOFFSET to switch from one timezone offset to another.
What version are you on?
Does the .Net DateTime contain information about time zone where it was created?
I have a library parsing DateTime from a format that has "+zz" at the end, and while it parses correctly and adjusts a local time, I need to get what the specific time zone was from the DateTime object.
Is this possible at all? All I can see is DateTime.Kind, which specifies if time is local or UTC.
DateTime itself contains no real timezone information. It may know if it's UTC or local, but not what local really means.
DateTimeOffset is somewhat better - that's basically a UTC time and an offset. However, that's still not really enough to determine the timezone, as many different timezones can have the same offset at any one point in time. This sounds like it may be good enough for you though, as all you've got to work with when parsing the date/time is the offset.
The support for time zones as of .NET 3.5 is a lot better than it was, but I'd really like to see a standard "ZonedDateTime" or something like that - a UTC time and an actual time zone. It's easy to build your own, but it would be nice to see it in the standard libraries.
EDIT: Nearly four years later, I'd now suggest using Noda Time which has a rather richer set of date/time types. I'm biased though, as the main author of Noda Time :)
No.
A developer is responsible for keeping track of time-zone information associated with a DateTime value via some external mechanism.
A quote from an excellent article here.
A must read for every .Net developer.
So my advice is to write a little wrapper class that suits your needs.
There is a public domain TimeZone library for .NET. Really useful. It will answer your needs.
Solving the general-case timezone problem is harder than you think.
You could use TimeZoneInfo class
The TimeZone class recognizes local time zone, and can convert times between Coordinated Universal Time (UTC) and local time. A TimeZoneInfo object can represent any time zone, and methods of the TimeZoneInfo class can be used to convert the time in one time zone to the corresponding time in any other time zone. The members of the TimeZoneInfo class support the following operations:
Retrieving a time zone that is already defined by the operating
system.
Enumerating the time zones that are available on a system.
Converting times between different time zones.
Creating a new time zone that is not already defined by the
operating system.
Serializing a time zone for later retrieval.
From the API (http://msdn.microsoft.com/en-us/library/system.datetime_members(VS.71).aspx) it does not seem it can show the name of the time zone used.
DateTime does not know its timezone offset. There is no built-in method to return the offset or the timezone name (e.g. EAT, CEST, EST etc).
Like suggested by others, you can convert your date to UTC:
DateTime localtime = new DateTime.Now;
var utctime = localtime.ToUniversalTime();
and then only calculate the difference:
TimeSpan difference = localtime - utctime;
Also you may convert one time to another by using the DateTimeOffset:
DateTimeOffset targetTime = DateTimeOffset.Now.ToOffset(new TimeSpan(5, 30, 0));
But this is sort of lossy compression - the offset alone cannot tell you which time zone it is as two different countries may be in different time zones and have the same time only for part of the year (eg. South Africa and Europe). Also, be aware that summer daylight saving time may be introduced at different dates (EST vs CET - a 3-week difference).
You can get the name of your local system time zone using TimeZoneInfo class:
TimeZoneInfo localZone = TimeZoneInfo.Local;
localZone.IsDaylightSavingTime(localtime) ? localZone.DaylightName : localZone.StandardName
I agree with Gerrie Schenck, please read the article he suggested.
Generally the practice would be to pass data as a DateTime with a "timezone" of UTC and then pass a TimeZoneInfo object and when you are ready to display the data, you use the TimeZoneInfo object to convert the UTC DateTime.
The other option is to set the DateTime with the current timezone, and then make sure the "timezone" is unknown for the DateTime object, then make sure the DateTime is again passed with a TimeZoneInfo that indicates the TimeZone of the DateTime passed.
As others have indicated here, it would be nice if Microsoft got on top of this and created one nice object to do it all, but for now you have to deal with two objects.
I am working in C#.net - .Net fx is 2.0 which doesnot support converting between different time zones. I have wrote a scheduler based on UTC but it is giving errors of 1 hour in the DTS periods for London. I need some solution so that I can gat the correct time in any timezone relative to UTC with correct DST adjustments.
Is changing to .NET 3.5 absolutely out of the question? It would make your life much, much easier. Otherwise, you're stuck with the plain TimeZone and DaylightSavings classes, as well as having to fetch the known timezones using P/Invoke.
William Stacey has a blog post with some code to do this - but I haven't tried it, so can't vouch for its accuracy. (In my experience he's usually pretty good though :) There are no doubt similar bits of code around if that one doesn't help you.
I believe that the API he's using doesn't have access to historical data, btw. In other words, it will assume that DST always kicks in on the first Sunday of October (or whatever the rule is) rather than knowing that the rule has changed over time. TimeZoneInfo in .NET 3.5 supports historical data where the OS does.