I've searched already for some ideas on this but the answers were totally code-based; my problem is also a HCI/Usability issue:
https://stackoverflow.com/search?q=[asp.net]+time+am+pm
I have an events form with a calendar. Then I have three drop down lists for Hours, Mins and AM/PM. But technically, 12 Noon and 12 Midnight are not AM or PM, correct?
http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight
I have thought about adding "Noon" and "Midnight" to the AM/PM drop down but I would be assuming that the user would know the correct usage (they won't). I could create the AM/PM as a cascading drop down based on the hour selected?
There are probably many ways to hack this up - but I'm looking for suggestions that take usability into account - simple and elegant solution anyone?
Simple solution would be not to use an ambiguous system, use the 24-hour clock instead and the problem goes away.
In modern western society 12:00am refers to midnight and 12pm to noon. the simple solution we normally employ is to avoid any form of confusion and use a 24:00 based time instead. It also results in one less drop down to select from in this case.
Related
We are use the Fullcalendar plugin for booking our events
Al lot of the events take place around midnight so often we see events starting at 22:00 and ending at 4:00. It is possible to insert these in Fullcalendar in the week view but it is a little tricky. It would make more sense to us to start the days at 8 in the morning and end at 8 in the morning so events will usually be visible in a single day.
I did not find this option in the documentation, so I would like to know if there is an existing implementation that does this job or else find a hint where I would start to enhance Fullcalendar to make this possible.
It is possible using the minTime and maxTime by setting them as the following.
minTime: "08:00:00",
maxTime: "32:00:00",
Here is a codepen showing this.
However it is quite buggy. If you try to put a small event into the time that would be the next day after 12PM, then the calendar does not really know what to do and the even will be be out of view. If the event is at least long enough to bring it to the next day past 8AM then it will be visible across both days. Due to the bugs with this method I would suggest using the calendar with its default minTime and maxTimes is the best approach.
Can anyone tell me the best way of calculating the end date of a recurring event from the number of occurrences and the pattern in which the event occurs.
For example:
I have an event which has start date as 10/07/2014 (Tuesday) and occurs every week on Tuesday. This event will end after 10 occurrences (say). So, the my method should return me the end date as : 12/09/2014
The method should also consider more complex situations like suppose if the event occurs yearly on first Monday of October and has total 10 occurrences.
(This isn't an answer which gives you a complete solution by any means, but hopefully it's a step in the right direction.)
Good luck. I've worked on an ActiveSync implementation, and recurrent events are fundamentally painful. You'll need to think about all kinds of corner cases - if something occurs every month on the 30th, what happens in February? What happens if it happens at 1.30am, and the clocks go forward or backward in the event's time zone so that 1.30am happens 0 or 2 times for a particular day?
Noda Time can help with this, but it doesn't provide a complete solution, partly because all the requirements will vary so much.
The important types you'll need to know about are LocalDate and LocalDateTime to provide time-zone-neutral dates/times, and Period which represents a not-necessarily-fixed period of time, such as "1 month". That will help with things like "add a week" - and there are methods on LocalDate for things like "next Monday after this date". It gets harder for events which are "weekly, on Monday and Wednesday" - you'll want to step through the weeks, working out which days occur within a particular week, until you've gone through all the events you need.
Noda Time 2.0 has the concept of "adjusters" which will make life somewhat simpler for things like "the first Monday of October" but everything you need to do can be done with Noda Time 1.3. (Don't wait for Noda Time 2.0, which I wouldn't expect to be released for another 6 months at least.)
I think my strongest pieces of advice would be:
Keep it simple. Focus on getting the right results first, then work out any optimizations you need. (For example, don't try to "guess" when the 100th instance of an event will occur - stepping through 100 instances with simple steps will be slower, but get you to the right answer. Do measure the performance, but make sure you have good tests before you optimize.)
Introduce your own types to represent exactly what you know about the event. Use the Noda Time types where they match of course, but don't be tempted to use an existing type just because it's quite like what you're trying to represent. The small differences will bit you eventually.
Make sure you know what you actually want the results to be. Write lots of tests. Date and time work is a naturally data-oriented domain, so invest in making it as easy as possible to write tests for all the corner cases you should be thinking of. (And you really should be thinking about them. Pay particular attention to leap years and time zones.)
Be aware that time arithmetic doesn't follow the normal rules of arithmetic - x + 1 month + 1 month isn't the same as x + 2 months
If/when behaviour surprises you, do come back to ask specific questions here. There aren't very many of us working on Noda Time, but questions tend to be answered quickly :)
I'm using fullcalendar 1.6.4 in conjunction with a Drupal 7 site; all is well except that I'm getting the wrong number of weeks for some months with weekMode set to "variable" or "liquid". For September 2013, I get four rows of weeks, which means that I lose the last two days of the month. Most other months appear correctly, although December 2012 is shown with 5 weeks (losing the 30th and 31st), and January, February, and October 2013 are all shown with 6 weeks (one more than is needed).
I've been doing some quick hacking around with the render() code where the starting and ending dates seem to be worked out, but haven't come up with anything clearly better. So: are other people seeing this / is it a known issue / have I screwed up something with my installation? Thanks!
I think there's a bug here: in fullcalendar.js's MonthView.render(), it looks like the AddDays computation of visEnd (l. 1984) is getting messed up by firstDay getting string-concatenated into the value instead of added. visStart may be getting similarly affected, since it does pretty much the same thing. In any case, I stuck the line firstDay = parseInt(firstDay, 0) after the var FirstDay... statement, and things are working properly for me. This may not be the preferred way of handling the matter, but I think something like this is going on. Opinions from other eyes?
This is not a Full Calendar bug, but instead a bug in the Drupal implementation of Full Calendar. Drupal allows users to override the "start of the week" option (values of 0 to 6). Drupal is incorrectly storing this value as a string instead of a number.
See Drupal issue I opened.
We have a really strange problem in xpages regarding dates, the Notesdocument we have contain a date field and the value is only a date, there is no time portion.
In the xpage I have specified to display the date as a date/time value. the date display correctly on the webpage but we are now getting reports from users who login at night (around midnight) and see the date as adjusted by one day. if the same people login at daytime the date is correct so this only seem to happend around midnight
I have tried to change my clock on my client to around midnight but that does not reproduce it so I assume this is a server issue.
The domino server have correct date/time and we are using the latest version of Domino
any ideas?
we encountered the same problem recently and, I believe, found a very nice solution.
system treats the pure date as a date in UTC time zone. Date value is automatically converted into server's time zone. So the question is how to prevent conversion?
this code prevents conversion:
<xp:this.converter>
<xp:convertDateTime
type="date"
ignoreUserTimeZone="true"
dateStyle="long"
timeZone="UTC">
</xp:convertDateTime>
</xp:this.converter>
pay attention at "timeZone" attribute.
The issue is related to not having the TimeZone specified in the date / time field. We ran into this just yesterday. If you don't have the TZ specified, it seems to assume UTC and will adjust accordingly. Include the time zone and your field will stop adjusting erroneously.
Perhaps it has to do with this ?
http://www-304.ibm.com/support/docview.wss?uid=swg21508734
I've seen some reports about XPages Dates and TimeZone Issues
I suspect your Domino version was 8.5.3, because there were 2 APAR, LO72278 and LO67745, on similar problems against 8.5.3. Fixpack 3 addresses them.
The root cause is that Lotus Notes allows you to save a "Date" with no time or zone and the Notes server has a default Time Zone setting to interpret these incomplete things called dates. XPages doesn't play by the same rules, and its master Java wants to know what zone you're using, and looks to the system for some clue, and generally will use midnight within some TZ to refer to a "Date". There is a whole region on Stack Overflow on the "how to store/represent a date" topic - [datetime] - since languages and DBMS each have their own approach.
Nice legacy Notes focused article about it.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/05022009100728PMAGU5MB.htm
XPages article about it
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/XPagesTimeZones.htm
Too bad they are not totally on the same page, I assume each release gets closer.
What's the broad math idea behind the calendar if you need to build one from scratch without depending on OS or other libraries ?
The broad math idea is finding out the day of the week for a specific day. Every time you print out a month, you must pick up the first day of that month an start from the right week/day. Like usual wikipedia has the answer:
http://en.wikipedia.org/wiki/Calculating_the_day_of_the_week
Also you will have to take into account leap years to make sure you print February properly.
I dont see any real math involved when building a calendar. Of course there is the problem of leap years, but this is no complex math, just applying the rule that there is one more day each four year, and this extra day is skipped every 100 years.
You do the math!
Btw, I think you're always dependent on OS since the OS provides you the current date and time. If you really want to be OS independent you have to get the current date and time from the BIOS.