Why? That sounds a very strange way to do things.
s ravi chandran wrote:. . .I am trying [c]reating a date with only time and another date with now(). Then appending the time from first date.
Stephan van Hulst wrote:Okay, I think I understand what you mean.
You want a certain task to run every day at a certain time. The user enters that time as a local time in a certain time zone. Every day, you can do this:
Dave Tolls wrote:I notice in your example you are using GMT.
What happens between the end of March and the end of October each year?
Is the user going to be OK with whatever it is running an hour later than they had specified?
Stephan van Hulst wrote:Your code is not correct. The application time consists of the wrong date if LocalDate.now() is a different date than the date of the current day in the entered time zone. You need to use the current date of the time zone.
You don't need to jump over difficult hurdles to get the current time. Just use Instant.now().
Stephan van Hulst wrote:What Dave means is, what do you intend your application to do when the user has selected a time zone that uses daylight saving time, and has selected a time that is either invalid for the date the clock is adjusted, or ambiguous?
For instance, if the user has selected 2:30 AM as the time to perform the task, in the timezone Europe/Amsterdam, what do you expect your application to do on October 29th 2017? And on March 25th 2018? Will the task be performed twice? Will it be performed at all? Will the application crash?
Enter 1:30am and there is a risk of the task never triggering at all. I shall leave verification of that assertion as an exercise for the reader.
Stephan van Hulst wrote:. . . on the 29th of October 2017, the task could trigger an hour earlier than the user intended, if they entered 2:00 AM. On the 25th of March 2018, the task could trigger an hour later than the user intended. . . .
s ravi chandran wrote:The important aspect here is the duration between current time retrieved and user defined application time.
Don't know; it would appear to do so when the clocks go forward, but I haven't tried it properly the other way.
s ravi chandran wrote:. . . Campbell,
Can I conclude that ZonedDateTime by itself provides time adjustment to us without any intervention from our end?
Stephan van Hulst wrote:Your post does not make sense to me. Are you saying that you don't care about the exact difference in time? The difference in time depends on the date, time and time zone. If you care about the exact difference, you should care about time zone rules.