This is a tricky scenario so I will try to explain myself well. We have a system that will have users in different time zones but that will have a program they all participate in that will expire and no longer be visible to them at midnight on a given date.
We are storing the dates in UTC but if we have a user in say India which is I believe 5:30 hours ahead of UTC so if we leave it as UTC for everyone they will be able to see the program for an additional 5:30 hours and if we have a user in Seattle which is -8:00 hours behind the program will end at 4pm. None of this takes daylight savings into account.
My question is what is the best way to handle this, I have spent hours searching and there are various options none of them ideal.
Add an option to their profile for them to select a timezone, will need to be translated, a fair amount of work, etc. If we allow them to change it they could set to a timezone that allows them to keep seeing items after they should have expired. Or we set a timezone and they can't change it but not very intuitive if they move, travel, etc.
Use the browser to get the offet by javascript, again open to abuse, changing dates, etc.
What is the best way to handle this? how are other people doing it? any help would be greatly appreciated.
Both these approaches are acceptable. It depends on wether user's location has an essential role in your program or not. It also depends on how 'virtual' the program is.
For example, if it shows wether some store is open or not than the second approach is better. It is also easier to implement and it really isn't that unreliable.
But if the program is virtual and the midnight is just an agreement than the first approach is better. Of course, it is more difficult to implement, but in the virtual world it looks much better.
Related
I have been searching the web for some simple world clock program that will run in the background without the use of internet connection. Instead I found this site using Google search: http://wwp.greenwichmeantime.com/info/global.htm
Now I would like some opinions on which language would fit best to the program I would like. Basically it will look like a simple 2 column table. Column 1 will be the time zone and column 2 as current time according its respective zones. It will just continuously run in the background while not consuming too much memory. The local time of the computer will be used as the base.
Again this will be an OFFLINE world time zone, so a desktop-application.
Features may include these as well but not necessary:
The time will be at 24 hour format to make it easier to read (well I find it easier and might be necessary).
Transparency setting.
Always on top.
I have learned some basic programming languages but don't know how to make this project in actuality since I haven't touched on the "visual" parts of the languages. I've seen some applications built on java but I haven't learnt it yet. I know basic python and basic C++.
Here's what I think it will look like: http://imgur.com/8ZdisWX
Just make it longer vertically so every time zone will fit.
First some notes. The page you link to show 24 timezones. This is for all practical use a lie. There are isn't 24 time zones, there are hundreds. 408, to be specific, of which several have more than one name, so there are 548 different names. http://en.wikipedia.org/wiki/List_of_tz_database_time_zones If you are on Windows, you might want to use Windows internal registry of time zones. It has fewer, but still hundreds of timezones.
Listing all of those is not practical. You will need a way for the user to select what time zones he wants to display. Many operating systems time/date widgets allow this already.
If you still want to do this application, then you can do this in any language whatsoever, more or less. Since you know basic Python I'd recommend you do it in Python, using pytz as the time zone library. As for GUI support, Kivy looks cool, and is very portable, even supporting iOS and Android.
Also note that time zones change often, so that you probably need to update your application a couple of times per year, just to get the latest time zone definitions. You can get around that in various more or less complicated ways. But I'd leave that for overcourse at the moment.
Normally, Rails stores all times in the database in UTC time. If you set your time zone to be something else, it converts automatically between that zone and UTC when you save to the database or retrieve from it.
What are some of the advantages of this approach? Are there any disadvantages? Is there any way to have Rails use a different time zone?
I think some of the advantages may be:
UTC removes the ambiguities of seasonal time changes
You can present different time zones to different users while keeping things consistent in the database
The only disadvantage I can think of is that, for an internal app where all users are actually in the same time zone, this difference makes it harder to run raw SQL queries based on local time.
This question has a little bit of a religious feel to it, but I'm going to answer it based on my personal experience.
Always store dates in an unambiguous form. Storing the date in UTC is pretty much the standard in that regard.
Advantages:
You can do simple math on date-times in the database without needing to convert them.
You can adjust the display of the dates at the presentation layer
Web applications can use a little bit of javascript to display local time
Disadvantages:
You need to convert all the times into some 'local' time on display
Localtime <-> UTC conversions incur a small processing penalty
Can you get rails to do something different? Possibly, but I've never tried as it just was too much work to fight what IMHO was a sensible design.
Does it make sense to use UTC from a 'just use my timezone' sense? Yes. Your server could be in California, your users in New York and who decides what is local time in that case. The server? The users? Mike, who just happens to be in London for the week on a business trip? In this case what timezone do you use?
I want to create reports for sequential, predetermined periods.
Essentially, I want to be able to:
Set a time period, for example from the 10th of one month to the 9th of the next. Then I want to be able to run a report and have the current period attached to the report, which in this example would be August 10, 2011 to September 9, 2011. Then suppose 6+ months later I run the report again, even though it's 6+ months later the period should be September 10, 2011 to October 9, 2011.
I've thought of creating a period model that would have 'begin', 'end', and 'current' fields. The 'begin' and 'end' fields would hold the numeric day values, i.e. continuing with the above example, 10 and 9 respectively. The 'current' field would hold the current end period date, which (using the above example) would be September 9, 2011. With the 'current' period and the 'beginning' and 'end' values I could then create the next logical period on demand. Further, I'd also have the opportunity to modify the period as needed.
While the above approach should work, it doesn't seem that efficient of an approach. Are there alternative approaches that are better? What can I do, if anything, to improve my approach?
Thanks.
There is an ideal technique to solve your problem. It's called test-driven development. It's ideal in this case since you can describe the solution without having to code it. Just by describing the solution, you develop many clues about what you should actually be coding.
Since you might really have no idea what code to write yet, Cucumber seems ideal in your case. You can describe the problem you want to solve in English, run that using Cucumber, and it will actually point you all the way towards the solution.
If you have some idea about what code you want to write, you might be better off using Test::Unit or RSpec directly. These methods are closer to the actual code: the problem you want to solve needs to be written in Ruby.
Pragmatic Programmer has excellent books about these two techniques.
Since the problem you've described is of particular value only to you, you will be hard pressed to find many actual implementations on StackOverflow I think. Using cucumber to describe the problem for yourself seems the best way to go forward.
I have strange problem and would like to use one of yours opinion.
I am setting up servers grid, all will be based in UK at first and then expand to other countries. My problem is should I stick with GMT or use BST, what is your opinion in terms of global timezone settings?
I don't quite know where are you going to set 'global timezone', but if you want to know my opinion, I would always store time-related information in UTC (not in GMT, there is slight but important difference between them) and convert it to local user timezone upon displaying. That's just safer method.
BST have one inconvenient property – Daylight Saving Time. It changes so, there are dates that does not exist and dates which are here twice (I wrote few words about it on my blog). If you want to convert timezones, there could be an ambiguity. So just stick to UTC and there should be no problems with conversions.
I would like to build a calendar 'component' for my website. I want to make it manageable and easy to extend in the future. I will not be using it for any other website but it want to make it solid independent of the rest of the website. The website is built with ASP.NET MVC.
I want to include different views (month, week, day [maybe even year]). I'm planning on using different ways to present information to the users:
Icons
Colorization (weeks, hours, periods[!])
Popup screens
The information needs to be displayed based on information contained in other (.NET) models. I want this logic to be separated correctly.
I'm fairly good at javascript, so I will be able to build a nice interface for dragging and dropping events on the calendar and navigating through the calendar dates. However I want the component to work without javascript too.
Should I build this component from scratch? If so, can you name the different parts which you would create to build the component?
OR
Can I alter the .NET Calendar control to fit my needs?
Thanks for the input!
I'm heavily biased here, but have a look at what Google Calendar does. To my mind it's a really, really nice web UI for calendaring.
My main advice would be to expect it to be a pain. In particular, each of these "axes" adds an extra order of magnitude of complexity:
Interoperating with other calendar clients (e.g. iCal or ActiveSync)
Interoperating with other calendar servers (e.g. Google Calendar)
Handling time zones (do not assume that a time zone is just an offset from UTC! You need to know more information so you can predict when daylight saving kicks in, account for historical/future changes etc)
Handling recurrent events (which can end up being arbitrarily complicated if you're not careful)
Handling shared events (e.g. meetings)
Handling shared access (e.g. user X is user Y's secretary and has permission to do various things)
Handling localization (every culture displays its dates in different ways)
Handling different calendar types (do you need to support Coptic calendars etc?)
When you combine all of them, you end up with a huge pain. Work out what you really need to cover, and rule out everything else. Try to rule it out permanently (and explicitly - keep a document of things you're just not going to support, with management approval).
Full disclosure: I work on Google Sync for mobile devices, mostly on the calendar side. You wouldn't believe some of the corner cases that come up. My development space is mostly made up of corners, basically.
why reinventing the wheel if you can reuse and maybe improve an already good one ?
try to look at the DHTMLxScheduler it uses a Javascript API so you can do everything you need ...
you can read more on WebAppers entry
In the world we are today, we should reuse instead of inventing again and again the some thing over and over... at least I'm apologist from this idea.
Open Source - GPL allows you to use dhtmlxScheduler in GPL projects for free.
I would definitely discourage you from building your own. Think about this for a minute.
If you expect building a calendar will take you say X hours, then you should spend X/10 hours looking for a calendar that:
Comes even halfway close to what you need. At worst you'll waste 10% of your time with a potential gain of saving 50% of your time. I know there hundreds of calendars out there so you'll probably find one that fits your needs almost entirely i.e. with progressive rendering and all (drag and drop is something you'll probably need to do yourself).
Has a license that suits your needs. Most of them have liberal licenses because it's such a common control.
If the calendar has high adoption you'll be better off because it will have fewer bugs since it will have been tested in the wild but yours will continue to show bugs across the vast array of browsers months down the line. You really don't want so spend your time fixing bugs when you could spend that same time coding features. If the community is big it might even have cool features that you can get for free without even having thought of them (like shifting the start of the week from Mon to Sun for some countries).
You can focus the time saved building on drag and drop functionality and tweaking the calendar to your needs.
I agree with rest of the answers...you can use some library for that, for example jquery ui calendar:
http://jqueryui.com/demos/datepicker/
cheers