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.
Related
moment version is 2.24.0
My date value is 2019-04-23 03:16:00 +0000 UTC
I use moment to let it become to Asia time just like:
const moment = require('moment');
const localTime = moment(date).format('YYYY/MM/DD HH:mm');
<Text>{localTime}</Text>
localTime will show 2019/04/23 11:16
It works when I test it on debug mode.
But when I close the debug mode localTime will be
invalid date
The issue happen both of Android and IOS.
Any ideas ?
For anyone else experiencing date/time issues with Moment on Android especially if you're moving from React Native 0.59 (or older) to 0.60+, it appears that Hermes changes the way the Android works with Moment/dates. However, it would work when the debugger was enabled. Turns out, when you run the debugger, it switches back to the Chromium engine (or V8?) from Hermes. Resulted in us having to use console logs to track down Moment parsing issues. Oddly, the issues also occurred when trying the same manipulations in Safari.
If you're parsing dates passed in via different vars for day, month, year and the day or month does not have preceding zeroes (ex: 01 vs 1) then I recommend doing this:
const momentFormat = { y: birthYear, m: birthMonth, d: birthDay };
return Moment(momentFormat).format('MMMM Do, YYYY');
This manually sets the values rather than relying on each value being correctly formatted or having to write custom code to ensure the day/month values have the 0 when needed.
I'm inheriting some code, and I've got two of their tests that are still failing, not sure if they were before, or if it's because I have a different version of Jasmine (they were pre 2.0)
The test that is failing has this spy setup in the beforeEach
spyOn(datacontext, 'getImportLogForDate').and.callThrough();
Then in the test
controller.DepositDate = new Date();
controller.PerformActionThatCallsGetImportLogForDate();
expect(context.getImportLogForDate).toHaveBeenCalledWith('1', controller.DepositDate);
The resulting error is confounding because they are identical
Expected spy getImportLogForDate to have been called with [ '1', Date(Thu Dec 04 2014 13:00:51 GMT-0600 (Central Standard Time)) ] but actual calls were [ '1', Date(Thu Dec 04 2014 13:00:51 GMT-0600 (Central Standard Time)) ].
Can I not verify functions have been called with a Date?
What is PerformActionThatCallsGetImportLogForDate doing with the date object? Jasmine compares date objects by their millisecond value so if it's off even by 1ms, they won't be equal, but you won't see that level of detail just reading the console output.
Alternatively, you have 2 other options.
Just test that a date object was used as the 2nd argument.
expect(context.getImportLogForDate)
.toHaveBeenCalledWith('1', jasmine.any(Date));
Test that date value, but outside of a toHaveBeenCalledWith, in case of some specific weirdness with that matcher.
expect(context.getImportLogForDate.calls.mostRecent().args[0])
.toEqual('1');
expect(context.getImportLogForDate.calls.mostRecent().args[1])
.toEqual(controller.DepositDate);
I have found that when using toHaveBeenCalledWith for a specific Date, jasmine.objectContaining works great.
it('#userChangedMonth calls fetchData with end of month', () => {
spyOn(component, 'fetchData').and.returnValue(true);
const calendarChangedTo = new Date('2018-10-10 00:00:00');
const endOfMonth = new Date('2018-10-31 23:59:59');
component.userChangedMonth(calendarChangedTo);
expect(component.fetchData).toHaveBeenCalledWith(jasmine.objectContaining(endOfMonth));
});
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.
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?
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"