I am currently using #DateTimeFormat in a domain object as follows:
#DateTimeFormat(pattern = "MM/dd/yyyy")
private Date startDate = new Date();
In a Spring MVC Controller, I am posting today's date: 10/19/2011 using the jQuery UI Date picker, and I confirm that this is being sent as an HTTP Post parameter using firebug as follows:
startDate=10%2F19%2F2011
Unfortunately, once it gets to Spring on the server, it stores the date as 10/18/2011 - there is an off-by-one day error.
There is nothing in my code that even remotely touches the date - there is no calculations or anything going on with regards to this date.
Is there something about #DateTimeFormat that I should be aware of?
Could something in Hibernate be responsible for changing the date too?
I'm also looking at the my database for this application. I am storing another date, called creationDate which is an actual timestamp and differs from user input. In most cases, the dates are the same but the client wanted the ability to set it differently so that is what startDate is for.
Start Date Creation Date (actual timestamp, not user input)
2011-04-17 19:00:00 2011-04-17 21:32:27
2011-04-18 19:00:00 2011-04-18 21:14:01
2011-04-20 19:00:00 2011-04-20 23:06:47
2011-04-26 19:00:00 2011-04-26 23:24:34
2011-04-28 19:00:00 2011-04-28 20:07:06
2011-05-01 19:00:00 2011-05-02 13:35:37
2011-06-21 19:00:00 2011-06-22 15:06:36
2011-07-28 19:00:00 2011-07-29 15:32:35
2011-09-03 19:00:00 2011-09-04 13:11:45
2011-10-11 19:00:00 2011-10-12 11:45:14
2011-10-11 19:00:00 2011-10-12 11:49:55
2011-10-18 19:00:00 2011-10-19 02:20:43
At first it seems like it was a bug started in May, but then I realized that the date is correct if it was over 19:00:00, and it's off-by-one if it's under 19:00:00.
I hate Java :(
The problem seems to occur when Spring creates a date given 10/19/2011 - it seems to translate that user input and formats it to 2011-10-18 19:00:00.
What is the simplest solution?
Thanks
It seems very likely to me that this is actually a matter of time zones. A Date object represents an instant in time - I suspect if you look at the exact value that you've got (e.g. in UTC, to keep things clear) you'll get a better idea of what's going on. Chances are that where you're seeing "10/18/2011" you're interpreting it in a different time zone.
If Spring supports converting to Joda Time types I'd suggest using that instead - then you can use LocalDate which really does mean a date instead of an instant in time.
I've found that starting your JVM with your local timezone specified in the arguments solves this issue. For me it was just adding this line to the run configuration:
-Duser.timezone="Asia/Dhaka"
Related
Laravel carbon is returning time in UTC when printing Carbon::now() but doesn't give the correct time while using shiftTimezone and setTimezone
Below are the results:
Carbon::now(); //"2021-07-20T07:30:29.775871Z"
Carbon::now()->timezoneName; //UTC
Carbon::now()->shiftTimezone('Asia/Kolkata'); //"2021-07-20T02:00:29.452997Z"
Carbon::now()->shiftTimezone('+05:30'); //"2021-07-20T02:00:29.452997Z"
Carbon::now()->shiftTimezone('Asia/Kolkata'); //"2021-07-20T07:30:29.775871Z"
In case of shiftTimeZone, it should add 05:30 hours to the time. But what it actually does is reduces 05:30 from the UTC time.
And for setTimezone it is taking the same time as UTC.
Any idea where I'm getting it wrong?
In my application, I never use shiftTimezone or setTimezone.
I always go with something like the following:
Carbon::now()->timezone('Asia/Kolkata');
It returns me the date in Asia/Kolkata timezone, without any issue.
What you put in comments here is not the content of the instance, it's an UTC ISO-8601 string as it's converted to be rendered in JSON output for instance:
echo Carbon::now()->format('Y-m-d H:i:s.u p'); // 2021-07-20 09:36:08.596951 Z
echo Carbon::now()->shiftTimezone('Asia/Kolkata')->format('Y-m-d H:i:s.u p'); // 2021-07-20 09:36:08.596951 +05:30
echo Carbon::now()->shiftTimezone('+05:30')->format('Y-m-d H:i:s.u p'); // 2021-07-20 09:36:08.596951 +05:30
echo Carbon::now()->shiftTimezone('Asia/Kolkata')->format('Y-m-d H:i:s.u p'); // 2021-07-20 09:36:08.596951 +05:30
JSON is converted to UTC because it's a standard way to exchange datetime information, timezone should be a separated information and you only need it to force a timezone, but 99% you want the user/client/browser to use its own timezone so new Date('2021-07-20T09:36:08.596951Z') in JavaScript or equivalent in other languages will work just fine and apply the current device timezone, which is the correct way for proper localization. Very specific cases where you want to display a date in a timezone that IS NOT the user device timezone, then you should pass "Asia/Kolkata" explicitly in your JSON output.
I'm sending LUIS a query that is based on a time value (e.g. "what is the time 10 minutes from now" - just an example). I want the time to come back in the local timezone, so on the LuisPredictionOptions object (C#) I set the TimezoneOffset (as an example I set it to 2 hours ahead, or 120 minutes).
In Fiddler I can see when it calls the LUIS endpoint it's correctly adding "timezoneOffset=120.0".
However, the timezone comes back as UTC - it doesn't matter whether the timezoneOffset is set, or even what it is set to, the time always comes back UTC, using the builtin datetimeV2 entity.
Does anyone know what the TimezoneOffset property is for? Am I just using it incorrectly? Is there another way perhaps to get a local time from LUIS?
[Update]: Here are some examples: https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/[AppId]?verbose=true&timezoneOffset=0&subscription-key=[subscriptionkey]&q=/luis/v2.0/apps/c1be57f4-3850-489e-8266-db376b82c011?timezoneOffset=120&log=true
https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/[AppId]?verbose=true&timezoneOffset=0&subscription-key=[subscriptionkey]&q=/luis/v2.0/apps/c1be57f4-3850-489e-8266-db376b82c011?timezoneOffset=240&log=true
and I'm trying the following example utterance: "in 10 minutes".
When I do this, the timex is in UTC (e.g. timex=2020-01-11T16:08:25) and the "value" comes back with the same value, minus the "T", as follows: value=2020-01-11 16:08:25
I could understand perhaps if the timex is in UTC, but then possibly "value" should be adjusted by the timezoneOffset?
It looks like there's an incorrect question mark in your URL, right before timezoneOffset.
Using the same query I was able to get the expected behavior, where the returned value is different by 10 minutes.
Which SDK are you using? Perhaps you're using the V3 Runtime SDK which uses the V3 endpoint that doesn't use timeZoneOffset but instead uses datetimeReference, and need to use the V2 Runtime SDK instead.
https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/[app-id]?verbose=true&timezoneOffset=10&subscription-key=[key]&q=in 10 minutes
The TimeZoneInfo class's FindSystemTimeZoneById method can be used to determine the correct timezoneOffset based on system time. An example in C# is shown below:
// Get CST zone id
TimeZoneInfo targetZone = TimeZoneInfo.FindSystemTimeZoneById("Central Standard Time");
// Get local machine's value of Now
DateTime utcDatetime = DateTime.UtcNow;
// Get Central Standard Time value of Now
DateTime cstDatetime = TimeZoneInfo.ConvertTimeFromUtc(utcDatetime, targetZone);
// Find timezoneOffset
int timezoneOffset = (int)((cstDatetime - utcDatetime).TotalMinutes);
Reference:
https://learn.microsoft.com/en-us/azure/cognitive-services/luis/luis-concept-data-alteration?tabs=V2#c-code-determines-correct-value-of-timezoneoffset
I have an Instant coming from a source that should, according to the specs, be a LocalDate, but don't see any methods in the LocalDate class to convert the Instant to a LocalDate.
What is the best way to do this?
Java 9+
LocalDate.ofInstant(...) arrived in Java 9.
Instant instant = Instant.parse("2020-01-23T00:00:00Z");
ZoneId zone = ZoneId.of("America/Edmonton");
LocalDate date = LocalDate.ofInstant(instant, zone);
See code run live at IdeOne.com.
Notice the date is 22nd rather than 23rd as that time zone uses an offset several hours before UTC.
2020-01-22
Java 8
If you are using Java 8, then you could use ZonedDateTime's toLocalDate() method:
yourInstant.atZone(yourZoneId).toLocalDate()
Other answers provided the mechanics for the transformation, but I wanted to add some background on the meaning of such transformation which hopefully helps explain why it works the way it works.
LocalDate and Instant seem similar – they both hold date(/time) information without the time zone information. However, they have quite a different meaning.
Instant represents a point in time unambiguously. The representation does not explicitly contain any time zone, but implicitly it refers to the UTC time line.
LocalDateTime (and LocalDate) is ambiguous, because it represents a point in the local timeline, which implicitly refers to the local time zone.
So, in order to correctly transform an Instant into a LocalDateTime (conceptually – some of these steps are bundled together into a single operation in the implementation) you need to:
1. convert the Instant into a ZonedDateTime by applying the UTC time zone info
2. change the time zone from UTC to the local time zone (which implies applying the relevant time zone offset) which gives you another ZonedDateTime (with different time zone)
3. convert the ZonedDateTime into a LocalDateTime which makes the time zone implicit (local) by removing the time zone info.
Finally, you can drop the time-part of LocalDateTime and end up with the LocalDate.
If using java 8 you can do the following
Instant instantOfNow = Instant.now();
LocalDate localDate
= LocalDateTime.ofInstant(instantOfNow, ZoneOffset.UTC).toLocalDate();
You need to ask yourself at what zone offset you want to transform it to most probably and when you know the answer to that:
LocalDate.ofInstant(yourInstant, yourZoneOffSet)
EDIT
just realized that this is only possible since java-9, for a pre-java9 see the other answer
Complete running example, Java 8 compatible:
import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;
class Scratch {
public static void main(String[] args) {
Instant now = Instant.now();
LocalDateTime ldt = now.atZone(ZoneId.systemDefault()).toLocalDateTime();
System.out.println(ldt);
}
}
Instant instant = Instant.now();
LocalDate localDate = LocalDate.ofInstant(instant, ZoneOffset.UTC);
the above code worked for me.
I've written a scope that returns all objects with a transfer_date from the beginning of the current year to the end of the current year.
scope :year, lambda { where("transfer_date BETWEEN ? AND ?", Time.zone.now.beginning_of_year, Time.zone.now.end_of_year) }
This works well and gives me the objects that I need. But now I'm looking to write a scope that does the same thing but for the previous year. I know there's no method in the Time class for beginning_of_last_year so I'm thinking that it might be better to define a class method instead of a scope.
If I wanted to return all objects with a date between the beginning of last year and the end of last year, what would be the best way to express this in Ruby?
I've written this as a scope but I think it can be cleaner:
scope :previous_year, lambda {where("transfer_date BETWEEN ? AND ?", Time.zone.now.beginning_of_year - 1.year, Time.zone.now.end_of_year - 1.year)}
There are a few optimizations I'd make here.
Since you already have ActiveSupport loaded and you're using it, make use of the ago method, and write something that's a little more flexible. You can also use a range and ActiveRecord can handle writing the appropriate query for your DB, no string substitution needed.
scope :from_year, ->(date) { where(transfer_date: date.beginning_of_year..date.end_of_year) }
# usage
Record.from_year(1.year.ago)
This is a lot less rigid. You can now easily query for records that are from 5 years ago without writing any new code. If you find yourself using last year in a lot of places, make it a convenience method:
def self.last_year
from_year 1.year.ago
end
How about this:
(Time.zone.now - 1.year).beginning_of_year
(Time.zone.now - 1.year).end_of_year
I use this line of code
scope :last_year, lambda {where(transfer_date: 1.year.ago.all_year)}
irb(main):032:0> 1.year.ago.all_year
=> Thu, 01 Jan 2015 00:00:00 UTC +00:00..Thu, 31 Dec 2015 23:59:59 UTC +00:00
Why does this say 13 instead of 14?
Time.parse('2014-01-08 14:01:00 +0300').hour
# => 13
The time is parsed correctly, but displayed in your local time zone.
This happens in my console:
Time.parse('2014-01-08 14:01:00 +0300')
=> 2014-01-08 12:01:00 +0100
Note the +0100.
http://apidock.com/rails/Time/use_zone/class
should help you to get time in correct time zone
Time.use_zone(zone name) accepts block. Inside this block application uses time zone you've provided in zone name
use_zone(time_zone) public
Allows override of Time.zone locally inside supplied block; resets Time.zone to existing value when done.