I am using angular-strap to save date and time for a project, but the time being displayed is not the same time being saved. I can not find any information anywhere on fixing this issue. Has anyone else had this problem?!
Screen shot of data
The value 2015-04-21T09:00:00.000Z means we are talking about the specific point in time described as "The 21. of April in the year 2015, at 9 o'clock UTC". That is, it includes a time zone denoted by the trailing Z. The timepicker you use automatically presents that value to the user, the exact same point in time, but takes the time zone his system is set to into account.
TL;DR The value is correct. Use this value for calculations and store this value in your database. Whenever you present this value to a user, convert it to his time zone.
Related
I cannot for the life of me figure out how to default the time of day in DateRangePicker to 00:00:00 for start date and 23:59:59 for end date.
The time of day simply defaults to the current time on the computer, which, frankly, is rarely what the requirements for a date range are. So It's hard for me to imagine there is no way to do what I'm trying to do. Check out the screenshot:
Here I picked the date range of Apr 22 to May 4. But notice the time of day. In order to set those to 00:00:00 and 23:59:59 respectively, I have to click on those times and scroll around to pick specific time of day, which is super annoying to do every time.
The documentation says nothing about the time. Also their GitHub issues page does not address this. What am I missing here. It seems like such an obvious oversight to not allow you to set a default time of day.
You can set the default time on the calendar via defaultCalendarValue.
<DateRangePicker
format="yyyy-MM-dd HH:mm:ss"
defaultCalendarValue={[new Date('2022-02-01 00:00:00'), new Date('2022-03-01 23:59:59')]}
/>
This has also been updated in the example on the rsuite official website.
https://rsuitejs.com/components/date-range-picker/#date-time-or-time
I’m trying to work with date-fns-tz in my react-based webpage and couldn’t make the following use-case to work.
I have a date input in a form that should be submitted to the backend that stores the data in local timezone.
A user in GMT+2 timezone selects 14:00 on 1/Feb/2021 in the UI, which correlates to 1612180800 timestamp (as the UI was opened in GMT+2), but it should eventually get sent to the backend as 14:00 in GMT-8, which is actually 1612216800 timestamp.
What’s the right way to get this conversion (from 1612180800 --> 1612216800 ) to work?
I tried to work with various date-fns functions, but hadn’t found the right one.
You'll need two things to make this work correctly:
An IANA time zone identifier for the intended target time zone, such as 'America/Los_Angeles', rather than just an offset from UTC.
See "Time Zone != Offset" in the timezone tag wiki.
A library that supports providing input in a specific time zone.
Since you asked about date-fns, you should consider using the date-fns-tz add-on library.
Alternatively you could use Luxon for this.
In the past I might have recommended Moment with Moment-TimeZone, but you should review Moment's project status page before choosing this option.
Sticking with date-fns and date-fns-tz, the use case you gave is the very one described in the docs for the zonedTimeToUtc function, which I'll copy here:
Say a user is asked to input the date/time and time zone of an event. A date/time picker will typically return a Date instance with the chosen date, in the user's local time zone, and a select input might provide the actual IANA time zone name.
In order to work with this info effectively it is necessary to find the equivalent UTC time:
import { zonedTimeToUtc } from 'date-fns-tz'
const date = getDatePickerValue() // e.g. 2014-06-25 10:00:00 (picked in any time zone)
const timeZone = getTimeZoneValue() // e.g. America/Los_Angeles
const utcDate = zonedTimeToUtc(date, timeZone) // In June 10am in Los Angeles is 5pm UTC
postToServer(utcDate.toISOString(), timeZone) // post 2014-06-25T17:00:00.000Z, America/Los_Angeles
In your case, the only change is that at the very end instead of calling utcDate.toISOString() you'll call utcDate.getTime().
Note that you'll still want to divide by 1000 if you intend to pass timestamps in seconds rather than the milliseconds precision offered by the Date object.
You can use 'moment' to convert timezone.
1.Create a moment with your date time, specifying that this is expressed as utc, with moment.utc()
2.convert it to your timezone with moment.tz()
For example
moment.utc(t, 'YYYY-MM-DD HH:mm:ss')
.tz("America/Chicago")
.format('l');
I am using the AMAZON.DATE slot and I would like it to default to past dates.
For example, if a user says Monday I would like it to automatically select last Monday rather than next Monday.
In the documentation it confirms that it defaults to 'on or after the current date':
"Utterances that map to a specific date (such as "today", "now", or
"november twenty-fifth") convert to a complete date: 2015-11-25. Note
that this defaults to dates on or after the current date (see below
for more examples)."
For my application there is no way a future date would make sense so it wouldn't be too difficult to manually program this in but I just wondered if there was any other way of doing it?
No, you cannot change the behavior of built in slots, so if Alexa resolves user's answer as a date - before passing it to your further processing just subtract 7 from resolved value. It will give you the date in the past.
I am working with getting previous date for various time zone based on the current date.Right now in my code, I got the US current time in milli seconds and then setting the time which in another Calendar object.
Then I am modifying that Calendar object Date with negative values to get previous dates.
When I checked, Calendar object is returning different values than the values which I set.May be I did not understand how Calendar object works.
Please explain why the time is different.
Below code gets the current time in US
Timestamp currTimeInGMT = DateTimeUtils.getCurrentTimeInGMT();
Timestamp currTime = DateTimeUtils.convertDateTime(currTimeInGMT,TimeZone.getTimeZone("GMT"),TimeZone.getTimeZone("PST"));
Using the above code, I am getting Current US time as September 18 1.12 AM Then I am converting the time into milli seconds using this code
Long currentTimeInLong = currTime.getTime();
Then I am setting the above time in Calendar object
Calendar yesterdayCal = Calendar.getInstance(TimeZone.getTimeZone("PST"));
yesterdayCal.setTimeInMillis(timeInMillis);
After setting the time,
First I tried to get time from Calendar object using yesterdayCal.getTime(), I am getting September 18 1.12 AM
Then I tried to get Date, Hour, Minute using below code
Date=yesterdayCal.get(Calendar.DATE)
Hour=yesterdayCal.get(Calendar.HOUR)
Minute=yesterdayCal.get(Calendar.MINUTE)
I am getting the following results.
Date=17, Hour=12, Minute=42
Why I am getting two different results for two methods getTime() and get().
As #mwe answered, if it sets the time in UTC, then I should get the same time for both the methods even if its wrong time.
Please explain clearly, as I am really confused with these methods
If you use setTimeInMillis it sets the time in UTC.
So you have to add the time difference to you time zone, PST, to the long value.
yesterdayCal.setTimeInMillis(timeInMillis+8000l);
new Date(moment().year(), moment().month(), moment().day(), vm.newHearing().HearingTime().split(":")[0], vm.newHearing().HearingTime().split(":")[1]).toLocaleString()
The client side value for a date column is 11/5/2013 10:15:00 AM. The time is selected from HTML5 time input control.
When I check in database after saving the entity, it shows me incorrect time value:
11/5/2013 3:15:00 PM
It appears that you are using moment.js, which is fine except you aren't using it properly
Try this instead:
moment(vm.newHearing().HearingTime(), "HH:mm").toISOString()
That will pass the selected time, on the current day, from the user's local time zone, converted to UTC time and in ISO format.
Now that might not be exactly what you want to do. Depending on your requirements, you might instead want this:
moment.utc(vm.newHearing().HearingTime(), "HH:mm").toISOString()
Which is almost the same thing except that it assumes the input time is already in UTC.
Or you might want this:
moment(vm.newHearing().HearingTime(), "HH:mm").format("YYYY-MM-DDTHH:mm:ss")
This one doesn't try to convert to UTC at all.
For all choices, I emit the date string in ISO8601 format. Since you are sending it back to the server, this is the best choice. When you used toLocaleString, that generates a format that is appropriat for display only.