0.1 Timezones Specification

Authors: Bobby Rullo Last edited: Dec 21, 2005 Creation date: Dec 21, 2005
Reviewers: 

Overview

Goals and Objectives

Timezones are necessarily part of any calendering application, but issues involved in handling them properly from the server-side to the client-side are complex. For the initial release of Scooby we need something that works well enough for the early Scooby users while allowing us to release relatively quickly without having to plan out the full timezone implementation.

Since most Scooby users will be Chandler users who have shared their Calendars via Cosmo, we cannot simply ignore Timezones. At the same time, issues regarding the UI and Timezone repositories have not been solved yet. The solution then for now is for Scooby to preserve and display events with timezones already entered, but Scooby created events will have no such info - the events will be so-called "floating events" without a timezone.

High Level Use Cases

1. View events created in Chandler (or other sources) with Timezone info intact

2. Create a new event in Scooby

Definitions

Requirements

         
Timezone display: Events with timezones will be displayed on the Week view so that the time they occur in the user's local time (as determined by the browser's canvas) will be the location where their event blocks are placed. The time displayed on the event block though will be the correct time according to the event's timezone. (mde, I know you don't like this and you have a point...maybe we need a different default behavior)

In the detail view all information will be displayed - the Timezone name, the time relative to the users local time, and the time in the event's timezone.

Timezone preservation: If a user edits an event in Scooby that has a timezone, that timezone will be preserved.

New Events: New events will have no timezone info and thus will be floating events.

Assumptions

High-level Decisions

Terminology


User Interface / Interaction

mde to fill out...

Code Design

Specials Considerations

QA / Test

Any info that will be useful for testers. Special cases or scenarios to consider.

API / Developer Platform

If relevant, how the feature will be made accessible to coders?

Security

Aspects of the design dealing with potential security issues.

Internationalization / Localization

Things to keep in mind for Internationalization. Caveats known at design time.

Accessibility

UI must be accessible (Section 508).

Build / Install

New info that coders need to know introduced by that feature. List here known dependencies in particular.

Cuts

Useful Links


History

Author Edit date Description
br December 21, 2005 Creation