I'm modifying and old app and I found a big bug. I'm in Spain and this app is reading some files here which contain a date in a UTC string format, and is needed to be converted.
The string value is already converted to local time with CDate due to the format:
"yyyy-MM-yyTHH:mmZ"
But the code here converts again the date to a local value with .ToLocalTime, presumably making the time change again to a incorrect value.
The strange fact occurs now, where the var is taking the correct value, but the code is not returning that. In the "Inspection" secion in the Visual Studio you can see that the result should be 0, not 22 (hour 0 of next day).
What is happening here?
EDIT:
The app is reading a XML file, and in this point is reading this:
<IntervaloTiempo v="2013-10-26T19:33Z/2013-10-26T22:00Z"/>
The code is the one shown in the screenshot:
Valor = Split(.Value, "/")
dtUTC = CDate(Valor(0))
iHoraIn = Hour(dtUTC.ToLocalTime().AddHours(1))
I corrected the code with this, and the app is working the same way:
iHoraIn = dtUTC.AddHours(1).Hour
EDIT2:
Since it looks that my post is difficult to understand as seen in comments, I'll try clarify on some things.
I'm using Visual Studio 2005 with .NET Framework 2.0.
The value in dtUTC is converted to local time and its value, as you can see in the screenshot, is 21:33, which should return 22 with AddHour(1).Hour.
When using dtUTC.ToLocalTime() its hour should be converted to 23:33 value, which should return 0 with AddHour(1).Hour.
As you can see in the "Inspection" window, that is the behaviour. The problem is, the final value of the var iHoraIn is 22, which is correct, but the code is not.
Actually, changing the code to just deleting the ToLocalTime() part makes the final value the same.
Can someone explain why and how this is happening? Is this a bug?
DateTime.Kind
In Version 2.0 of the .Net framework, Microsoft introduced the DateTime.Kind property. The different kinds are as follows:
Local
Unspecified
Utc
Every Date (the underlying CLR type is DateTime) object has the Kind property, which specifies what kind of date that object is. That is, it specifies whether the date value is local, UTC, or unknown.
If a Date object has Kind = Local, then no conversion is performed when the ToLocalTime function is called. From the DateTime.ToLocalTime method, emphasis is mine:
Kind Results (of ToLocalTime)
----------- -----------------------------------------
Utc This instance of DateTime is converted to local time.
Local No conversion is performed.
Unspecified This instance of DateTime is assumed to be a UTC time,
and the conversion is performed as if Kind were UTC.
How does this apply to your situation?
When you use CDate, the resulting Kind is Local. This means that when you call ToLocal on it, no conversion takes place:
Dim valor = "2013-10-26T19:33Z"
Dim dtUTC = CDate(valor)
' dtUTC.Kind is Local
' The following does not do any conversion
Dim dtLocal = dtUTC.ToLocal()
A more complete example
This example shows what happens when you use CDate, and what happens when the Kind is explicitly set. The first two code blocks are equivalent - CDate creates a Local date. The third block shows what happens when you specify a UTC date.
Sub Main()
Dim valor = "2013-10-26T19:33Z"
Dim dtUTC = CDate(valor)
Dim dtLocal = dtUTC.ToLocalTime()
Dim iHoraIn = Hour(dtLocal.AddHours(1))
Dim kind = dtUTC.Kind
printDate(dtUTC, dtLocal, iHoraIn, kind)
Dim dtUTC2 = DateTime.SpecifyKind(dtUTC, DateTimeKind.Local)
Dim dtLocal2 = dtUTC2.ToLocalTime()
Dim iHoraIn2 = Hour(dtLocal2.AddHours(1))
Dim kind2 = dtUTC2.Kind
printDate(dtUTC2, dtLocal2, iHoraIn2, kind2)
Dim dtUTC3 = DateTime.SpecifyKind(dtUTC, DateTimeKind.Utc)
Dim dtLocal3 = dtUTC3.ToLocalTime()
Dim iHoraIn3 = Hour(dtLocal3.AddHours(1))
Dim kind3 = dtUTC3.Kind
printDate(dtUTC3, dtLocal3, iHoraIn3, kind3)
End Sub
Sub printDate(ByVal dtUtc, ByVal dtLocal, ByVal hora, ByVal utcKind)
System.Console.WriteLine("UTC: {0}, UTC KIND: {1}, LOCAL: {2}, HORA: {3}", dtUtc, utcKind, dtLocal, hora)
End Sub
The above produces this output:
UTC: 2013-10-26 09:33:00 PM, UTC KIND: Local, LOCAL: 2013-10-26 09:33:00 PM, HORA: 22
UTC: 2013-10-26 09:33:00 PM, UTC KIND: Local, LOCAL: 2013-10-26 09:33:00 PM, HORA: 22
UTC: 2013-10-26 09:33:00 PM, UTC KIND: Utc, LOCAL: 2013-10-26 11:33:00 PM, HORA: 0
So what you are seeing is not a bug - it is expected behavior. You are trying to convert what you think is a UTC Date; however in reality it is really a local date.
I believe what you are expecting to see is what happens in the third code block above. It creates a UTC date and converts it to local time.
what happen here is
Sub Main()
Dim valor = "2013-10-26T19:33Z"
'this convert to local time
Dim dtUTC = CDate(valor)
'this add one hour to local time in 24 hour format
'equal to dtUTC.AddHours(1).Hour
Dim iHoraIn = dtUTC.ToLocalTime.AddHours(1).Hour
End Sub
2013-10-26T19:33Z is 2013-10-26 15:33 in my time zone, dtUTC show this time
i'm adding 1 hour to it so iHoraIn is now 16
in your screenshot, the watch show dtUTC as 9:33 PM which is 21 hour
you add 1 hour which now is 22 hour
is this what you expect?
Related
I have below code where I format the time value to be date format.
const arrivalDateTime = moment(
`${todaysDate.format("YYYY-MM-DD")} ${arrivalTime}:00:00`,
).toDate();
When debug mode is off, if I select 8 or 9 value from the control, its not able to format the value.
When I am in debug mode, and select 8 or 9, its able to format the value as:
Fri May 22 2020 09:00:00 GMT-0600 (Mountain Daylight Time)
I have seen many threads discussing the same issue but solution provided in them haven not helped me to format this correctly.
I am trying to print arrivalDateTime value, it shows like this in log ;
Date { NaN }
I am trying this but it does not work, it days toDate is not a function :
moment().format(`YYYY-MM-DD ${arrivalTime}:00:00`).toDate();
Took me a while but I finally figured it out.
this helped me
This didn't work:
const arrivalDateTime = moment(
`${todaysDate.format("YYYY-MM-DD")} ${arrivalTime}:00:00`,
).toDate();
This worked:
const arrivalDateTime = moment(
`${todaysDate.format('YYYY/MM/DD')} ${arrivalTime}:00`,
).toDate();
// note that engine does not seem to like parsing with ' - '. so I changed it to ' / '
still not sure the reason behind it.
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
My company uses a software that, in the footer of it's about section lists the year 2001-2002. Is this sufficient grounds to believe that the last major overhaul or update that this program received would have been in 2001-02?
If not, is there a way through decompiling the software, it's written in VB6?
I forgot the linker sticks a timestamp into the PE Header. Here is a short VB.NET applet to read the PE Header and convert the timestamp:
Private Function GetPEDate(filename As String) As DateTime
Dim dtUINT As UInt32
Using fs As Stream = New FileStream(filename,
FileMode.Open, FileAccess.Read),
rdr As New BinaryReader(fs)
' move to PE location (60; 70 for 64 bit but
' there is no such thing as a 64bit VB6 app)
fs.Position = &H3C
Dim peHDR As UInt32 = rdr.ReadUInt32() ' offset of start location
fs.Position = peHDR
Dim tmpUINT = rdr.ReadUInt32() ' PE sig
Dim tmpShrt = rdr.ReadUInt16 ' machine
tmpShrt = rdr.ReadUInt16 ' sections
dtUINT = rdr.ReadUInt32() ' linker timestamp
End Using
' SEE NOTE
Dim dtCompiled As New DateTime(1970, 1, 1, 0, 0, 0)
dtCompiled = dtCompiled.AddSeconds(dtUINT)
dtCompiled = dtCompiled.AddHours( _
TimeZone.CurrentTimeZone.GetUtcOffset(dtCompiled).Hours)
Return dtCompiled
End Function
To use it:
Dim dt = GetPEDate(FullFilePath)
Console.WriteLine("App was compiled approx: {0}", dt.ToString)
Output:
App was compiled approx: 4/6/2004 11:54:07 AM
I tested this with some actual old VB6 apps as well as some x86 VB.NET apps and the DateTime returned is spot on compared to that of CreatedDate and/or Modified Date reported by Explorer.
Initially the time was off by 3 hours. The MSDN docs clearly state:
This field holds the number of seconds since December 31st, 1969, at 4:00 P.M.
But it was off by exactly 3 hrs and my TZ is not 3 away from East Coast US, Seattle or GMT. A quick Google yielded this article by Jeff Atwood (which includes another PE reader). Changing the base date to 1/1/1970 00:00:00 and adding the UTC adjustment returns times matching Explorer.
Apparently MSDN is wrong or out of date as to the base date. 1/1/1970 also seems more likely since corresponds to POSIX/Unix timestamps.
From WinNT.h note second DWord, TIMEDATESTAMP
typedef struct _IMAGE_FILE_HEADER {
WORD Machine;
WORD NumberOfSections;
DWORD TimeDateStamp;
DWORD PointerToSymbolTable;
DWORD NumberOfSymbols;
WORD SizeOfOptionalHeader;
WORD Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
If you look here you'll find above explained and a program to do it for you as well.
https://msdn.microsoft.com/en-au/library/ms809762.aspx?f=255&MSPPError=-2147217396
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"