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.
Related
Just upgrading from Laravel 5 to Laravel 6, and with that Carbon is also upgraded to version 2.
Running in to a weird problem with Carbon::parse(). It seems that no matter what I put in as the second argument to parse - the date is always parsed with the apps default timezone (Europe/Stockholm).
$bookingDate = Carbon::parse('2020-08-17 15:00:00', 'Europe/London');
$bookingDate->getTimezone()->getName(); // Europe/Stockholm (mismatch)
However, using Carbon::createFromFormat(), it works as expected:
$bookingDate = Carbon::createFromFormat('Y-m-d H:i:s', '2020-08-17 15:00:00', 'Europe/London');
$bookingDate->getTimezone()->getName(); // Europe/London
This is not a problem when testing in, for example, tinker - as there is no default timezone set in that execution.
So why ->getName() in the first code returns Europe/Stockholm?
You can parse using this:
Carbon::parse($value)->format('d/m/Y');
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
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.
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"
i am using datepicker to insert date on my form, which of course returns date to the controller as a string.
the issue is when I try to convert this string to date, I get an error "invalid date"
Date.parse(params[:abc][:date])
To verify if I'm doing it right, I wrote the following ruby program:
string_date = "06/18/2011"
date = Date.parse(string_date)
puts date
This works perfectly fine. But when I try the same thing in my rails controller, it gives invalid date error.
please help.
When I do this in my Rails 3.1 console:
date = Date.parse("06/18/2011")
I get an "ArgumentError: invalid date" exception. However, it works fine with an ISO-8601 date:
date = Date.parse('2011-06-18')
So perhaps you're having a locale problem. Your script could be using your standard locale setting (which is probably some US locale judging by the date format) but your server is probably using something else.
Try changing the jQuery datepicker date format to something standard and unambiguous by adding this:
dateFormat: 'yy-mm-dd'
to the datepicker's options. The datepicker's default is 'mm/dd/yy' and Ruby's Date class doesn't like seem to like it without a special locale setting.