I have a very unusual problem and I'm stuck for several days.
I implore your help :-).
When my Californian customers order on my Prestashop, time is the order confirmation emails is wrong.
All times are in the New York time zone (this one I selected for my store).
How can I ensure that my Californian customers have right timezone in their emails? Same thing for European customers?
Thanks in advance.
Related
We are having a lot of transactions on the site, so for this reason we are re-cycling our booking confirmation numbers/ order id numbers on the confirmation screen which is set into our purchaseID . Since we are re-using our booking confirmation number, in order to make our purchaseID unique we are adding timestamp to our purchaseID variable using pipe delimeter. So formula looks like:
purchaseID = order_id + '|' + timestamp (current date).
My concern here is, let's say I make a booking today and my purchase id looks like -
purchaseID = 5747118 | 6-7-2019
Now I access my confirmation screen again tomorrow and after 2 days, 3 days and so on and I see adobe calls firing. Because I accessed my confirmation page on different dates my timestamp changed and thus my purchaseID is not unique anymore. Even though I am seeing my same booking confirmation page my purchaseID is not unique now. Does this mean, every time i view my confirmation screen on a different day my booking/revenue would be counted multiple times ? If yes, what's the best way to tackle this issue ?
So it sounds like someone can go to your site, make a purchase and see the confirmation page, and then later on, go back to the same confirmation page without actually making another purchase. Maybe they bookmarked the page and come back to it later for reference. Or maybe they refreshed the page, because reasons.
Does your site charge their credit card for accessing the page again? I sure hope not. Your site/coding should be structured in a way that does not keep charging the customer more money every time they view the page again.
And your code logic for outputting Adobe Analytics should be structured in the same way: your coding logic should be that you only output purchase event and variables (e.g. purchaseID) when a purchase actually occurs.
In practice, this sometimes isn't easy to do because of how the site is structured. So part of why purchaseIDexists is to de-duplicate purchases, so that if purchase event and data is re-popped, it will be de-duped. But it only works if you output the same purchaseID when the visitor refreshes the page or otherwise comes back to it later on (where they aren't actually making another purchase).
Which it sounds like you were doing with the original booking confirmation number you pushed to purchaseID. But things went south when you decided to throw a current datestamp into the mix because you started recycling booking confirmation numbers. Well you can't do that. You can use a dynamic value such as the current date/timestamp as part of the value, but you must remember it, and output it in the future.
Maybe this involves adding an extra column to your database with the date/timestamp of purchase (which I have to assume you surely already have), and then pull that value when you pull the booking confirmation number.
Or maybe the solution involves stepping back and rethinking the fact you are recycling booking confirmation numbers. This seems like a bad idea to me. It's definitely a bad idea for your Adobe Analytics implementation, as you have seen for yourself. But is this not a bad idea in general? What happens if a customer buys something today and has # 12345 as proof of transaction to reference, and then tomorrow, a week, a year or whatever from now, some other customer gets the same number?
It stands to reason that you will end up with a mess on your hands, trying to sort out which customer bought what. Transaction ids by their nature are supposed to be forever unique to the transaction. So my very first recommended solution to you would be to stop recycling your booking confirmation numbers. Move to a different format if you need to (e.g. UUID).
Failing that, my next recommendation would be what I said a couple paragraphs up, about storing the date/timestamp in a column at the actual time of purchase (which surely you already have), and then grab and use that value along with the booking confirmation # to use as delimited value, instead of generating the current date on the fly (which absolutely does not work).
In my app, users can select a time that they want to receive a daily email. I then regularly run a script to find users who have an upcoming email to send and send it. So, if users elect to have an email that goes out at 7AM, I look for users with that selected as their time and send it.
The problem is of course timezones. I'm going to have users in different timezones and need 7AM to always be 7AM, regardless of timezones or daylight savings.
I can understand how to do it for display purposes, but I can't find much info on executing queries that have to factor in the timezone and DST for a collection of users with varying times and timezones.
This can probably be most easily accomplished by simply saving everything in the database as UTC. You can adjust the times for display and incoming form data by using the users' specified time zone.
I am working on rails 4 application. I want to show the time for comment I created. If I open the site in india then time should be shown in IST (according to indian standard) and If I am in USA so for the same comment that i made in india time should be shown according to USA time zone.
What do I need to do in my config file for development and production?
Do I need to change anything in database?
Please help me.
Rails always saves times in UTC (universal time), and the server has a setting which tells it which timezone it (the server) is running in.
To show different times to the client, Rails (which runs on the server) will need to know which time zone the client is in. This isn't in a standard request header so you will need to get them to submit the information somehow. Once you know their timezone you can ensure that you always show times to the user using their timezone - there are helpers for this.
Getting their timezone can be done explicitly, eg by giving them a timezone dropdown in their "My Account" page, and then saving that in their user record, and/or by making it more upfront and forcing them to choose one in a popup, if you don't know it.
Or, you can do it for them using Javascript, passing it through in a cookie. See this article for an example of how to do it.
http://thisbythem.com/blog/clientside-timezone-detection/
Well one solution can be to store the time zone of the user in the database, write a filter
around_action in your ApplicationController which would set the Time.zone to the time_zone from the database field.
You might want to look at Time.zone and TimeZone in the rails api
Here is a railscast , you can figure it out from the comments and the github link.
I'm trying to find a way to design a set of rails relationships for a billing application. It is for a vendor who receives checks from an insurance company, or payor, and then forwards the payments on to their clients.
The vendor balances checks and payments by the month and sends reports to the client based on activity within that month.
The 'month' however does not directly correspond to the calendar month. Instead the clients are staggered in tiers so that reports are not all due on the same day of the month. For instance, in the month of January a Tier 1 client might have their activity defined as Jan 01-Jan 31, Tier 2 as Jan 07-Feb 06, and so on.
There are exactly 3 tiers.
Each tier has many clients.
A client has many checks.
So far, so straightforward.
I just can't work out how to effectively manage the months:
A check has a deposit date, by which it will belong to a particular 'month'. The month is also necessarily determined by the tier of the check's client.
Since there are three tiers, is follows that there should be three 'January 2013' months, each with different start and end dates, but the uniqueness of 'month-year' and tier should be validated such that tier 1 has exactly one 'January 2013', and so on.
I want the routes to be such that a user can navigate to the clients_path, choose a client, choose a month, and create a new check such that the check knows what month and client it belongs to, and I can't for instance create a new check with a deposit date outside of the range defined by client_month_path.
I think the error I am getting into is perhaps in defining each model as having a has_many or belongs_to relationship, such that a tier has many clients but also many months. But now a check will have two parents, so how do I unite the two?
Interesting question. This answer may not provide an exact answer to your needs and perhaps misses some crucial details, but I hope it can help you.
I think you can solve the 'month-problem' if you stick to some base rules, like:
Make a clear distinction between real calendar dates and tier months. Never pass just one date to some service method or view, always pass both. Therefore:
Store both the real date and the tier month on every check/record necessary. One is a date, the other a month. You might also wish to store the tier_id if it exists.
Only update the tier month attribute when the real date attribute changes. The tier month is always calculated and validated according to some client settings. This is done somewhere in your model and no where else.
Those rules will save you from a lot of date shuffling in the rest of your code. If you ever find yourself recalculating what tier-month a check is in, you're doing it wrong. Also, having the tier-month available in every record gives a huge advantage in more complicated queries.
Create methods in the appropriate models (or service objects) for all those business-logic questions. What is the tier date-range for this client in this calendar month? Can this check be dated like that? Do not rely on validation only, sometimes its fine to ask those questions in another context than a save operation, say when rendering a calendar view.
About the queries with two parents. I don't think this is a big problem. In essence you only create an extra WHERE clause on most queries. For example you can solve that in a controller with a before_filter that fetches (and perhaps authorizes) the desired client, month and check. These before_filters will only vary slightly across controllers.
I hope this will help a bit.
I'm working on a Rails application that's kind of like a blog. Users create Entries. I'm trying to work out how to handle time storage and display. I've read this writeup about Rails timezone support.
It's great but it doesn't cover what my app needs to do. It only looks at cases where you want to convert stored time to the current logged in user's time zone. In contrast, the effect I want is...
A user creates an entry in California at 10:00 a.m.
A couple years later he moves to New York and then at some point looks at his old entry. The "created" date should say "10:00 a.m." He doesn't care about time zones. He just wants to know what time of day he felt like it was when he wrote the entry.
If he then edits the Entry in New York the displayed "modified" date is, again, his subjective time of day when he made the edit. (Let's assume he went to "preferences" and changed his time zone setting when he moved.)
Also, for the sake of thoroughness, the app should be able to report the "real" absolute time when an Entry was created or updated.
(Note -- my imaginary user is a guy, but for women it should work roughly the same way.)
The way I'm thinking of implementing it is...
Have the attributes User#time_zone, Entry#created_at_utc, and Entry#updated_at_utc in addition to the standard created_at and updated_at.
The user selects their time zone from a menu when they sign up. (They can change it later if they want.)
The app uses User#time_zone to store created_at and updated_at in the user's subjective local time. If it's 10:00 a.m. for them, the app writes "10:00 a.m." to the DB.
The app also saves the current UTC time in the aforementioned _utc fields to deal with the last requirement above.
Is that a good way to do it? Is there a better way?
The two roads you can take are:
Store a timezone (UTC) in the user account as well as in every post - update the post's timezone along with the updated_at field whenever the user changes the post (if he or she has changed timezones).
Store the timezone only in the user account. When the user changes timezones, update every post that belongs to the user and add/subtract to the created_at/updated_at dates.
The first option seems like the cleanest option to take. For this you would only have to create a new method in your post record:
def locational_updated_at
updated_at + timezone.seconds
end
Where timezone is an integer containing the seconds since UTC.
If you can, you should avoid storing two different sets of timestamps, and you should avoid storing any non-UTC dates. Both of these things will lead to confusion. I'm not completely sure I understand what you're doing (though I like your idea of subjective time), but wouldn't it be enough to just attach a time zone to every post, and always use that zone to display the times? It would default to the time zone set in the author's account, so he could change it when he moved cross-country without affecting previous posts.
I think that's all you need--to attach a time zone to every post. Is that sufficient? Or am I missing some part of this?