I'm trying to convert a UTC to a CST by using the 'ConvertTimeFromUtc' method. However, the result is off by 1 hour compared to what I got when I try to convert it manually online.
StatusDatetime is 2017-06-05 21:14:39.6216795
TimeZoneInfo.ConvertTimeFromUtc(StatusDatetime.Value,
TimeZoneInfo.FindSystemTimeZoneById("Central Standard Time")).ToString("hh:mm
tt")
Try using Central Daylight Time instead of Central Standard Time, as we are in daylight savings time.
Related
How to obtain the date from a file without the influence of windows time settings ?
I'm trying to read date file with VB but I obtain a difference between the time writes on file properties (WDT) and the time returns by VB (VBT), due to daylight saving time
If I read a file saved during winter time in summer, I have a difference of VBT = WDT+1h. And in the same case, if I read a file saved during summer in winter, I obtain a difference of VBT = WDT-1h.
You need to convert the DateTime(s) to UTC and compare those times. This is the time without any adjustment for daylight savings, etc.
There is an extension of the DateTime type ToUniversalTime that returns the UTC value:
https://msdn.microsoft.com/en-us/library/system.datetime.touniversaltime(v=vs.110).aspx
Example:
Dim currentDateTime = DateTime.Now
Debug.WriteLine(currentDateTime.ToString)
Debug.WriteLine(currentDateTime.ToUniversalTime.ToString)
Outputs on my machine (UK Time Zone +1h from UTC for British Summer Time)
15/04/2016 12:21:04
15/04/2016 11:21:04
Note that there is also a DateTime.UtcNow if you want the current system time directly in UTC
I am trying to get the last modification time of a file in S3 using the ObjectMetadata method getLastModified(), as in the following snippet of code:
S3Object s3obj= some_s3_object;
Date someDate = s3obj.getObjectMetadata().getLastModified();
// What time zone is someDate in?
I'm getting back a value, but I am wondering what time zone it is in, and if I can rely on that being in the same time zone? I can't find a reference to the time zone in the docs or anywhere else - maybe I missed it somewhere?
In the course of using the debugger to examine the actual date value, I discovered the fact that the Date's TimezoneOffset is actually set to PST which is the locale of the server.
We have a VB.NET application installed on a customer's PC running XP, on which it appears that DateTime.ToLocalTime() has stopped working.
The problem first manifested itself in August 2013.
The customer is based in Texas, and their timezone is correct.
The documentation for DateTime.ToLocalTime() has the following interesting note:
On Windows XP systems, the ToLocalTime method recognizes only the current adjustment rule when converting from UTC to local time. As a result, conversions for periods before the current adjustment rule came into effect may not accurately reflect the difference between UTC and local time.
Therfore it appears likely that a timezone rule change was introduced in the August Windows Update, which has caused this.
I've found the following: http://support.microsoft.com/kb/2863058 which indicates that a cumulative timezone update was applied in August 2013, but no USA rules seem to be implicated in this change.
Has anyone else had experience of this problem, and (of course) a solution?
Edit
To clarify a bit. The times in question are stored in UTC in a SQL database, and we're converting to LocalTime for display. It's the display which is causing the problem.
Events which were recorded at 1500 localtime are now showing as recorded at 2100.
Will you be able to recode the product for the client?
You can use the Format function or the DateTime.Now, which gives you the date and time details of the local computer
Here give it a try:
Textbox1.text = DateTime.Now.ToString("yyyy-MM-dd hh:mm:ss tt")
Textbox1.Text = Format(now, "yyyy-MM-dd hh:mm:ss")
you can change the date time details inside the string, just remember y=year, M=month, d=day, h=hour, m=minute, s=seconds.
If you have a back end database though, I'd recommend getting the time from it. (which would depend on the database)
This is just a guess, since you didn't show any code. (Please show code in your questions, it makes it much easier to help!)
Texas is currently in Central Standard Time, which is UTC-6. Since there are 6 hours difference between the times you reported (1500, 2100), my guess is that you are converting twice somehow.
This shouldn't happen under normal conditions, thanks to the .Kind property attached to the DateTime. For example:
DateTime dt1 = new DateTime(2013, 11, 22, 3, 0, 0, DateTimeKind.Utc);
Debug.WriteLine("{0:HH:mm} ({1})", dt1, dt1.Kind); // 3:00 (Utc)
DateTime dt2 = dt1.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt2, dt2.Kind); // 21:00 (Local)
DateTime dt3 = dt2.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt3, dt3.Kind); // 21:00 (Local)
But if somehow you loose track of the kind and it is set back to "unspecified", then the double conversion can happen:
DateTime dt1 = new DateTime(2013, 11, 22, 3, 0, 0, DateTimeKind.Utc);
Debug.WriteLine("{0:HH:mm} ({1})", dt1, dt1.Kind); // 3:00 (Utc)
DateTime dt2 = dt1.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt2, dt2.Kind); // 21:00 (Local)
// somehow, the kind is getting set back to unspecified in your code
dt2 = DateTime.SpecifyKind(dt2, DateTimeKind.Unspecified);
DateTime dt3 = dt2.ToLocalTime();
Debug.WriteLine("{0:HH:mm} ({1})", dt3, dt3.Kind); // 15:00 (Local)
Now, it's unlikely that you are actually calling DateTime.SpecifyKind. Instead, I'd be looking in your code for some place where you store the local time back to the DB instead of the UTC time.
Or it could be that you convert the local DateTime to a string and read it back to another DateTime by parsing that string. That can happen in UI code. Perhaps you need to specify Local kind when gathering from a user on a form?
You should debug your code and step through so you can see how it is being transformed. I think then you will find the answer.
No, nothing happened in the Aug 2013 Windows Time Zone update that would affect the United States. The last DST change in the US was in 2007. Even then, you would be off by 1 hour, not 6.
Does anyone here knows how to solve the Tibco xpath daylight saving date issue.
The issue was we have one record 03/10/2013 02:00 parsed via Tibco mapping palette with following format (mm/dd/yyyy hh:mm). However, it got invalid date time error with above date. It worked with all other times, e.g. 03/10/2013 01:00, 03/10/2013 03:00, just not working with anytime between 03/10/2013 02:00 ~ 03/10/2013 02:59.
The current xpath we using parse-dateTime(format, string)
So, can xpath detect the daylight saving automatically with the inbound date format (mm/dd/yyyy hh:mm) and parse it?
Thanks so much.
James
Yes. The TIBCO function that parses dateTime does detect Day Light Saving.
I think you have two options to handle these cases in your engine.
Change the code to have a Java Code parse the dateTime. I am aware
that java correctly returns the time with 1 hour added in this case.
You should be able to do a TimeZone.getDefault() to get the server's
default TimeZone.
Change the java default timezone in the TRA - java.property.user.timezone in the designer.tra I suppose.
I have not tried these. :-)
I had the same problem with DST, trying to parse string 2014-03-30 02:00:00 which does not exist in italian timeZone.
Since the input date was perfectly legit (intended to be in GMT+0) I solved by forcing the timezone with this code. It should work with any other timezone as long as it doesn't support DST.
tib:parse-dateTime("yyyy-MM-dd HH:mm:ss Z"), concat($Start/root/dateTimeFrom, ' +0000')
Enable daylight in deployment.yaml (kubernetes)
- name: BW_JAVA_OPTS
value: "-Dbw.engine.enable.memory.saving.mode=true -Xms1024m -Xmx4096m"
I beat my head against this for a day and a half before it finally all came together, partly because I was fundamentally misunderstanding some things because of my assumptions of how things should work, and so the results I was getting seemed so completely irrational and confusing that I was starting to think things must be horribly broken in the libraries. They weren't.
This thread is to share my question, and what worked, partly because it seems to me that a lot of times a datetime record should be tied to the localtime of its location, and a lot of times when applications behave strangely with respect to timezone changes I think it's because they don't do that. So here's how to do that.
The easy part was using the TimeZone gem to get the location's timezone (I already have the latitude/longitude from using the GMaps4Rails gem), as described here: Ruby gem for finding timezone of location
Initially, I hoped each datetime could have an intrinsic and persistent time zone, even after being saved and retrieved from the DB, since we only care about the local time zone for each event. For the unusual and rare case where the datetime was needed in other-than-local-zone, I could convert. But I guess that doesn't exist since MySQL seem to have no concept of timezone with its datetime, and just stores everything as a plain ol' date and time.
So, that's fine -- the DB stores in UTC and I must do the conversions each direction.
How? (See below.)
User enters a datetime (year, month, day, hour, min, sec) in the appropriate local time for the event location. To save this as the correct UTC time in your DB, and retrieve later retrieve it and use it with its correct timezone, here's the recipe:
You must first set Time.zone = timezone -- where timezone is a named timezone string, like "America/Toronto" (GeoKit/TimeZone style) or "Eastern Time (US & Canada)" (Rails 3 style):
1.9.3p200 :001 > Time.zone = "America/Toronto"
=> "America/Toronto"
Note that it is nontrivial to map between the GeoKit/TimeZone style and the Rails 3 style. There is some support for that, but many of the mappings that GeoKit returns are not in the Rails mappings, so I'm sticking with the GeoKit/TimeZone names because they seem to work just fine, and I don't need user-selectable timezones because I'm taking care of all of that automagically for the user using the locations.
Now you can parse and save your datetime variable using ActiveSupport::TimeWithZone, and it will be encoded properly using the Time.zone parameter:
1.9.3p200 :002 > t = Time.zone.local( 2012, 8, 1, 12, 0, 0 )
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
i.e. In my case, for my Event model with instance event:
event.start = Time.zone.local( year, month, day, hour, min, sec )
event.save
When the data is saved to the DB, it is in UTC: 2012-08-01 16:00:00.000000
(Simulated below with call to t.utc)
1.9.3p200 :003 > t = t.utc
=> 2012-08-01 16:00:00 UTC
1.9.3p200 :004 > t.zone
=> "UTC"
Now, when you read it back from the DB, you need to again use the TimeWithZone support to tell the DateTime what timezone it is in.
Note that the in_time_zone function does not change the underlying datetime variable's timezone:
1.9.3p200 :005 > t.in_time_zone( "America/Toronto" )
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
1.9.3p200 :006 > t
=> 2012-08-01 16:00:00 UTC
1.9.3p200 :007 > t.zone
=> "UTC"
so you really need to assign the function output back to your datetime variable:
1.9.3p200 :008 > t = t.in_time_zone( "America/Toronto" )
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
1.9.3p200 :009 > t
=> Wed, 01 Aug 2012 12:00:00 EDT -04:00
1.9.3p200 :010 > t.zone
=> "EDT"
Finally, a warning -- do not use t.time! It's output is completely useless and irrational, with the time and it's timezone out of sync:
1.9.3p200 :011 > t.time
=> 2012-08-01 12:00:00 UTC