this might be stupid question, but ill ask anyway.
do i really need to implement gmt on site to get proper timestamp on a post? well im building a site like twitter. my feeds are working fine and showing me the time i need, like it shows "posted 11 minutes, posted yesterday, posted 5 days ago.. " just like this site, so i was thinking it should work for everyone properly, what you think? or do you think i need to implement gmt on it and do you recommand or have any article on it for implementing it proper way?
sorry if this sound stupid :O
In the long term, it is best to store time stamps always in GMT/UTC, no matter how the user interface is rendered. This has two advantages:
when changing the UI at some point, you won't need to touch the data
it gives a clear design guideline (in terms of a clear right/wrong decision): any specific function dealing with time can be independently reviewed wrt. processing timestamps in UTC
As for specific programming guidelines: these depend very much on the functionality you want to execute. Most of the time, you need either from-utc or to-utc operations.
It's a good point, but consider the case when 1 day ago suggests "yesterday", and it's currently 1:05am for some user. I suppose if you're using days = hours % 24 rather than days = datediff(then, now).days, then it would work fine.
I think the issue is: how accurate does your site need to be? If it's for medical readings, so someone can know when their medication is due, then yes, you want to account for timezones properly, and give accurate times rather than just "x ago". If it's just for "joe said hi two days ago", though, then it's not a big deal.
When you're talking about time periods like hours, minutes and seconds, then that's not even anything to do with timezones. Look at the timestamp of when it was created, and look at the timestamp now. Do some subtraction and voila!
The only time it's slightly strange is when you are in the range of a couple of days. Does yesterday mean "some time in the 24 hours prior to the last midnight", or does it mean "over 24 hours ago"? In any case, if the only level of granularity you are providing is "days", then once it's gone past about 2 days, then it doesn't really matter.
One nice way to avoid confusion is the same method used here on SO: put the readable, friendly date on the screen ("yesterday"), but put the exact time (in GMT or in the user's TZ) as a tooltip.
Related
Recently it came to our attention that our DB was using multiple timezones to record data, and or pass data around, and because of that data started going out of sync. So recently we made some changes to the data (accepting that some of the time data will be misleading or corrupt in the sense that its not 100% accurate. (well the old stuff at least)) That said, we have started making everything we can use GMT as times in/out the problem is now trying to use offsets according to a user defined offset from a predefined list.
So I can query accordingly and display it back to the user accordingly. Lets say I have a user from western america in the pacific time zone, that is an offset of -8, where as if I have someone in the eastern time zone thats a offset of -5
With that dates in and out are currently based on the user preference, where as everything is stored in GMT on the DB so how is it I can pass -N accordingly to something like gmdate() so I can query properly and display properly? I hope this makes sense to someone.
You can't just expect time zones to be a fixed number of hours apart. First off, daylight savings will break that notion, but asides from that, there are a few time zones that aren't hour aligned.
Take a look at this post:
How do you handle timezone difference calculation in PHP?
(There are many similar questions on stackexchange.)
You may want to take a quick look at falsehoods programmers believe about time and a followup with more falsehoods regarding time zones.
I have a question regarding Date and Time for MYSQL. Basically I started building a comments section for a web project I have going on. I was building out the DB table and wanted to know how the DB stores the date and time.
For instance if I am in LA and the time is 7:00 PM will it store the comment at 7PM and say that I am from New York obviously and I see the comment its 10 PM so what time will I see the 7PM that wouldnt really make sense. I am wondering how you solve this problem and differentiate between different time-zones.
I am imagining that the server has its own time zone associated with it so all time is delineated from that which would make things a whole lot easier. But is it right that a person sees their time from a post as 10PM when it was made at 7PM. This is all very confusing to me. Any information on how to regularly deal with this issue or if I have one at all will be greatly appreciated. I am building my site using PHP and Codeigniter.
I personally just store the times in the database under an INT ( 11 ) and use the native PHP time() function to get the time, and then you can convert this into a nicer format of a date using some of the PHP functions http://php.net/manual/en/function.date.php you can get the year, month, day, hour, minute, etc.
You then can easily just add or subtract the # of hours (3600 seconds in an hour) depending on the time zone. May be an easier way to do this, but this is how I am currently doing it :)
Ask the user their timezone and adjust times accordingly.
Show the timezone with the date ("9pm ET")
Do what StackOverflow does, and say "2 mins ago".
I'm developping an admin panel with ExtJS.
I've almost finished it except one thing: I need the "partner" who logs in to be able to configure when he/she works.
I'm like re-inventing the wheel, but thanks to ExtJS and my structure this won't be a problem.
The actual problem is about UI design:
I want to make very simple so that it's possible to enter very simple values like "I'm working each working days from 8 to 12 then 14 to 18"
I want to make it more configurable and be able to precise "I'm on vacation from july,1st until august,31th"
I want to make it even more configurable and be able to precise "the month of january, I'm working every single day from 8 to 20 non-stop".
I was looking for some inspiration with Microsoft Scheduler but to be honest, a basic user will never ever (ever x 87) be able to use such a UI to configure when he/she works
Same for unix cronjob. From my point of view, this is very hard to understand from a basic user's point of view.
So my question is: do you know where I could find some inspiration for this? And maybe if there are some Php components well written out there to handle such things...
Here's the way I did it: a "list" of rows that contains:
start hour
end hour
start date
end date
and a list of associated days.
This way it's possible to configure any kind of scenarii, even though it requires a bit of thinking, because you do not have to enter it a "natural" way (= you usually think first days of week you work, the hours and maybe the start/end days = it's the opposite of my configuration).
As the title states, I want to get the difference (in seconds) between 2 (specifically between now and a date in the past) dates without using: strtotime, the Zend Framework or a PEAR package.
I don't want to get into the details of my reason but the gist of it is that I'm working with very old dates (and I do mean old, I'm talking before 0 A.D.).
It is preferred that the returned result be highly accurate down to the second of the textual timestamp given. The format to call the function should be similar to:
$bar = foo("YYYY-MM-DD HH:MM:SS", "AD"); // Where AD is Anno Domini
$baz = foo("YYYY-MM-DD HH:MM:SS", "BC"); // Where BC is Before Christ
The first person who offers a working that features:
High readability
No magic (ternary operators, etc.)
Will have their answer up-voted and accepted. Their name will be credited in the header of the source file which uses their code.
EDIT (Re: Fame):
Someone said having a name credited in the header looks bad and can be edited out. I'm talking about the header of the source file that utilizes the function I want. This isn't about "fame". Credit should be given where credit is due and I have no need to lie about who authored a work.
EDIT (Re: Accurateness):
No reason other than I want to keep with the "letter of the message" as best as I am able.
EDIT (Re: Magic):
Magic is different things to different people. In regards to the ternary operator, please respect my opinion as I respect yours. Thank you.
EDIT (Re: Old Dates and One Second Accuracy):
As a student of history, it makes sense to me. The desire for "one second accuracy" is not an absolute. Perfection, while attainable, is not required.
I'd suggest splitting each datetime into parts (year, month, date, hours, minutes, seconds). Then, with each part, do a basic sum of most more minus less recent (remembering that a BC date is effectively a negative number).
You'll never get it absolutely correct. You're going to have to consider leap years, and whether a century year is a leap year, the switch between Gregorian/Julian dates etc.
Plus I'd love to know your reasoning for the limitations and high accuracy requirement!
For all such matters see Calendrical Calculations (Google for it).
Oh, and there was no year 0 AD, the calendar went from 1BC to 1AD, or rather, we modern westerners define the calendar that way, at the time most of the world was using other systems.
Or, make calls to on-line calculators such as this one and save yourself a lot of time.
Some languages and databases do date arithmetic, some don't. If you store your dates in a database, try postgres :
pg=> SELECT now() - 'January 8, 52 BC'::DATE;
-----------------------------
754835 days 20:27:31.223035
If you don't use a DB, then it gets a bit more problematic. PHP's date arithmetic is ... well, I'd rather not talk about it. Python's is very good, but it starts at year 1BC.
You might have to roll your own...
why don't you subtract the timestamps?
mktime(16,59,0,8,7,2001) - mktime(16,59,0,8,7,2000) = seconds between them
The company I work for creates applications for the Blackberry platform.
We've been working on a proprietary "analytics system" that allows us to embed code within our applications and have the applications report back some stats to our central servers every time they're run. Currently, the system works ok; however it's only in beta with 100-200 hits per hour. The "hits" are sent to the servers without a problem. We've built a very solid API to handle the acceptance and storage of the hits (in a MySQL DB). We've tested the load and we should be able to accommodate hundreds of thousands of hits per hour without a problem. That's not really a problem.
The problem is showing the stats. We've built a display panel similar to Mint's (haveamint.com), it shows the hits over each hour, the past days, months, weeks, years...etc. The fist version ran straight queries pulling data from the hits table and interpreting it on the fly. That didn't work for very long. Our current solution is that the hits are "queued" for processing and we have a cron come through every 5 minutes taking the hits and sorting them into "caches" for each hour, day, week, month, year...etc. This works amazing and it's incredibly scalable; however, it only works for 1 timezone. Since the entire company has access to this, we're dealing with a few hundred users in various timezones. What I define as "Today" in San Jose is MUCH different than what my colleague in London defines as Today. Since the current solution is only cached to 1 timezone, it's a nightmare for anyone who's checking the data outside of our timezone.
Our current plan to fix this is to create caches for every timezone (40 in total); however, that would mean that we're multiplying the amount of data by 40...that's terrible to me and given that the caches can be very large, multiplying it just sounds like a bad idea; plus, when we go to process the queue, it's going to take a lot more CPU time to put them in 40 different caches.
Any one else have a better idea of how to solve this problem?
(Sorry for such a long question..it's not exactly easy to explain. Thanks all!)
The solution you are proposing has too much redundancy. I would suggest you store the data in at least 30-minute buckets instead of hourly and the time zone be normalized to UTC.
With 30-minute buckets, if a user requests hourly data for 1 - 2PM from -4.5 UTC you can fetch data for 5:30 - 6:30PM from your system and show that. If you store data in one-hour increments you can't service requests to users in time zones with N + 0.5 hour differences.
For daily numbers you would need to aggregate 48 half-hour slots. The slots to pick would be determined by the user's time zone.
It gets interesting when you get to annual data because you end up having to aggregate 17,520 half-hour buckets. To ease that computation I would suggest you get the pre-aggregated annual data per UTC time and the subtract aggregate data for the first for 4.5 hours of the year and add aggregate data for the first 4.5 hours of the next year. This will essentially shift the whole year by 4.5 hours and the work is not that much. Working from here, you can tweak the system further.
EDIT: Turns out Kathmandu is +5.45 GMT so you would need to store the data in 15-minute buckets instead of 30-minute buckets.
EDIT 2: Another easy improvement is around aggregating annual so you don't have to add 17,520 buckets each time and without requiring one aggregate per country. Aggregate the annual data from Jan 02 - Dec 30. Since the maximum time-zone difference between any two countries is 23 hours, this means that you can take the annual data (Jan 02 - Dec 30) and add a few buckets before and after as appropriate. For example for a -5 UTC timezone you would add all buckets on Jan 01 after 0500, all buckets on Dec 31, and on Jan 01 the following year up to 0500 hours.
When designing software that touches multiple timezones, I'd say to always store your date/times in UTC with another field for the original timezone and have a function that takes the time and converts it to and from UTC/timezone. You'll save yourself a lot of trouble to handle the different cases of day switch, daylight savings, people looking at stats from a country from the other side of the earth and so on....
In your case, having the caches in UTC and just adjusting the requests to be converted in UTC should help. Don't store a stat as being "today", store it for hours 00:00:00UTC to 23:59:59UTC and when someone asks for the stats for today in New York, do the conversion.
As far as I can see, you are looking for the storage part of a data warehouse system here (your reports would be the front-end).
Actually, the way commercial systems are doing it, is the cache you described: Preaggregate your tables and create caches of them. The only way to accelerate your queries is to make the database system do less for them. This means less data, which in turn means less time spent in iterating the data or less data in the indices.
That said, I would either propose the "40 cache solution" (are there really more than 24 timezones). You should be able to trivially parallelize the sorting queue by creating copies of the data.
Another way to do this, would be to cache at hour granularity and then aggregate the hours into days (or 30 minutes if your timezones require this). This means you cache at a finer granularity than your daily cache but at a coarser granularity than the original data.
this kind of data is usually stored using round-robin or circular databases. check this http://www.shinguz.ch/MySQL/mysql_20070223.html and this http://techblog.tilllate.com/2008/06/22/round-robin-data-storage-in-mysql/ to know how they work and how to implement it under MySQL