Order confirmation email shows wrong timezone in summer time - email

When I created an order,the order confirmation email showed me the wrong time.
The order created time on order list of dashboard is correct, just shows EDT.
The "created_at" column of "sales_flat_order" table stores the order time as UTC.
Order email's time is "UTC+1".
I do have to show the EDT time on order email.
What's wrong?
On the winter time, Order email showed me "UTC".
After Mar 11,2018(on the summer time), the order email shows me the "EDT + 5" ( same with UTC+1).
Even though i changed the default timezone on Mage.php, locale.php and config.xml, the order confirmation email showed me the EDT+1 date.
It's very wired. Is there any solution?
I already matched the server time, web server time and store timezone.
Server timezone: EDT.
Web server timezone: America/New_York
magento timezone: America/New_York.
The time created in the email template {{var order.getCreatedAtFormated('long')}}
shows us the "UTC+1".
Hope good solution.
Comments: I debugged it on local server and live site.
When I get the time result on these codes, live site shows me the wrong time.
$order->getCreatedAt(); Local time output - UTC, Live output - UTC
$order->getCreatedAtStoreDate(); Local - EDT, Live - UTC+1(estimated result must be EDT as same with local server)
All sources are same because local source is a clone from live site
Live site uses the external database(RDS), but local server is not.
\app\code\core\Mage\Sales\Model\Abstract.php
/**
* Get object created at date affected with object store timezone
*
* #return Zend_Date
*/
public function getCreatedAtStoreDate()
{
return Mage::app()->getLocale()->storeDate(
$this->getStore(),
Varien_Date::toTimestamp($this->getCreatedAt()),
true
);
}

Solved this issue.
In the some modules, there were timezone reset code part.
It was settled as "EST".
After fixing it with UTC, the time of order email was corrected.
//date_default_timezone_set('EST');
date_default_timezone_set(Mage_Core_Model_Locale::DEFAULT_TIMEZONE);
Solved successfully.

Related

How to set the date of messages sent and received for exact time zone date time?

I'm trying to create an app of messages but the problem is to order the messages if one of the user don't have the time correctly set ( for example with 1 less minute ). So how can I set a default time zone that I can set the date of the messages according to this time zone date time and not the local ( device ) time? I tried using Timestamp.now(), NTP ( idk if i used it correctly but it was getting local time too) FieldValue.serverTimeStamp(); ( that was returning instance and the date was not working ). How can I solve this problem?
Whenever you save time take time in UTC like the following
DateTime.now().toUtc()
There can be one more issue in this approach. When a user has disabled automatic time setting and had manually adjusted time in the settings then it may result in inconsistent data too. To solve this you may try some api like worldclockapi.org. But there will be a small network delay to fetch time first then to save in your database. It's basically a trade off unless you have a server and save it in db taking time from the servers..
Use dart ntp package to do this.
DateTime sendTimestamp = await NTP.now();
print('Send timestamp: ${sendTimestamp}');
Every time we need to send timestamp from device, just get it from NTP.now().
Then to sync timezone between user app, use timezone packages.
final detroit = tz.getLocation('America/Detroit');
final timeZone = detroit.timeZone(sendTimestamp.millisecondsSinceEpoch);
print(timeZone);

Magento 2 - admin order grid, date filter not filtering correct orders

I have Magento 2.2.7 version installed and store timezone is set to India Standard Time (+05:30). Magento internally save order date and time in UTC and hence order placed date and time (India Standard Time) from store is different than what is saved in database table.
When I filter orders in admin by Purchase Date, it list orders filtered by UTC time not in the Indian Time. This doesn't show orders placed between 00:01 am to 05:30 am.
Is there any configuration in admin for this?
Note : I already search for this on google but didn't get any perfect solution.
This is configured at the admin user account level. Be warned, last time I tried setting an admin user to a none en_US locale setting it broke magento for them.

PayPal billing agreements REST API - how to start immediately

How can I start charging a user the user immediately for a PayPal billing agreement?
Here's what I've got so far.
Create a Billing Plan (POST .../payments/billing-plans/)
Make it active (PATCH .../payments/billing-plans/)
Create a Billing Aggreement (POST .../payments/billing-agreements/)
Send user to approval_url, user approves, redirected to return url
Execute agreement (POST .../payments/billing-agreements//agreement-execute)
This all seems to work, but I want to charge the user right now and every month in the future. If I set start_date to now in step 3 I get an error, it must be in the future. If I set it in the future the user is not charged.
Do I need to 'Set outstanding agreement amounts' then 'Bill outstanding agreement amounts' for the initial payment?
Also, what about monthly payments, do they require some action or do they just happen as specified in the Billing Plan?
Update
I'm testing this around 2014-09-16T20:06:30+0000
If I send start_date as the current UTC time it get an error at step 2 telling me it must be in the future.
If I send the current date +30 secs or +2 hours I get through to step 5 which returns a 400 response: UNKNOWN_ERROR "An unknown error has occurred"
If I send the current date +4 hours it all works. The current UTC time is 8pm so adding 4 hours means the start_date is tomorrow.
Does this mean I can't charge the user today? Does the start_date have to be in next day or even the next business day?
I've talked to a PayPal rep and found that start_date must be tomorrow or later. They are going to add this to the docs.
If you want to start monthly billing immediately you might be able to do it by setting the start date to be in one months time and charging a setup fee to cover the first month. I haven't tested this as it's not what I want.
First payment for agreements will be billed right on specified start_date. The subsequent amounts are also taken automatically by PP. You need to work with the BillOutstandingAmount calls only if PP failed to pick the payment on the renewal date.
The problem I faced when developing with their RestAPI was specifying a wrong timezone. Maybe this is the same for you. Make sure the proper timezone is specified in your start_date (with all dates given to PP in fact)
Dates should be in this format: yyyy-MM-ddTHH:mm:ssZ
ex. start_date = 2014-09-16T09:20:00-0400
IF you want to make sure Paypal accepts the date as being valid, just add a few seconds to it.
Let's say you are in Java, you can do something like:
private String getPaypalDate()
{
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
// Add 30 seconds to make sure Paypal accept the agreement date
Date rightNow = new Date(new Date().getTime() + 30000);
return df.format(rightNow);
}
I used this date format working.
$time = time();
$startDate = date('Y-m-d\\TH:i:s\\Z', $time);
I can't replicate, actually. I stumbled on this thread when getting the error due to setting it to moment.now(). But setting it to even 5 seconds in the future works a-ok. I'm using JavaScript, "start_date": moment().add({seconds:5}).format() and that checks out fine. Moment.js will set TZ to UTC when formatting as such, so it's gotta be a timezone thing on your end?
It looks like the payments just process based on the date being before or after 07:00 UTC of the current date.
For example. The current date time is 2017-05-04T04:50:00.00Z I set my start date to be the current UTC date time plus 30 seconds. Because the agreement date is set to a value greater then the current date time the API doesn't throw an error, but it DOESN'T set your time to be what you specified. Instead it sets it to 2017-05-04T07:00:00Z.
Now, if you have the same date time of 2017-05-04T04:50:00.00Z and instead of adding 30 seconds you add 24hrs you'd think that your time would then be set to be 2017-05-05T04:50:00.00Z. But no, the time will be set to 2017-05-05T07:00:00Z.
So it seems like these just process everyday at 07:00 UTC and you can't specify anything but the date.

Query across timezones

I'm developing an app where a user can request that an email be sent to them at a specific time every day in their timezone. For example User A lives in London and schedules an email at 2pm every day London time and User B lives in New York and schedules an email at 2pm New York time.
I'm wondering what way I should configure my database postgres such that a scheduler can fire every minute and query for all emails to be sent at that minute regardless of what timezone their in.
The one thing I want to avoid is having to run multiple queries, once per timezone.
Due to the (rather idiotic, quite frankly) rules for daylight saving times (DST) across the world, a local time can mean all kind of things in absolute (UTC time).
Save a time (not timetz!) and the time zone name (not the abbreviation) for when to send the emails. Tricky details under this related question:
Time zone names with identical properties yield different result when applied to timestamp
CREATE TABLE event (
event_id serial PRIMARY KEY
, alarm_time time -- local alarm time
, tz text -- time zone name
, ...
);
Use the following expression to "cook" the exact daily point in time, taking local DST settings into account:
SELECT current_date + alarm_time AT TIME ZONE tz;
Example:
SELECT current_date + '2:30'::time AT TIME ZONE 'Europe/London' AS alarm_ts
Returns:
alarm_ts
2014-05-19 02:30:00+02
Use timestamp with time zone (timestamptz) across your whole application. Be sure to understand how it works. This comprehensive post may be of help (also explains the AT TIME ZONE construct:
Ignoring timezones altogether in Rails and PostgreSQL
Just to be clear, once you have "cooked" the daily UTC time, you can translate it to and work with any local time just as well. But it might be less confusing to do all the rest in UTC.

GWT - Obtain Browser Timezone/Timestamp formatting

I send timestamps to my GWT client using GMT/Zulu time, with each string designated as such (ie. 2012-01-19T16:29:18Z, or 4:29pm GMT). How do I show this in the browser in the local timezone? So for me in CST I expect to see 10:29am.
If I do no formatting I get the date as 4:29pm, which I expect, If I use a TimeZone object of TimeZone.createTimeZone(0), I get for some reason 10:29PM (not AM as expected). I suppose I'm supposed to pass in something more meaningful than 0, but how do I obtain the right value for the where the browser is running?
J
You can get the time-zone offset that is configured in the browser using:
Date d = new Date();
d.getTimezoneOffset();
It won't give you the timezone name, I don't think that's possible to get.
Do you send the time as a timestamp, or string? I find the best approach is to send UTC timestamps to the client and then format them to whatever zone I need using DateTimeFormat/TimeZone. But I guess that if you are parsing the date string including the offset, you end up with a UTC timestamp anyway.
If you want the GWT client code to format the time in the browser time zone, you should pass the data from the server to the client as a java.util.Date object.