Skip to content
Browse files

Change TODO list to org format and add details

  • Loading branch information...
1 parent 81886ce commit da172855e2fb43e96e0ffcafc7758230b2ee0d1f @dlowe-net committed Dec 15, 2010
Showing with 99 additions and 87 deletions.
  1. +0 −87 TODO
  2. +99 −0 TODO.org
View
87 TODO
@@ -1,87 +0,0 @@
-- PARSE-TIMESTRING works fine, but we need a more human-friendly parser that
- can handle stuff like "08/03/2006 1:54pm CST". or maybe not? see
- http://chaitanyagupta.com/lisp/chronicity/
-
-- Support for other notational systems than the Gregorian
-
-- Ideally, local-time should have everything that the ruby Date class does,
- as well as the time functions in the venerable and honored clsql library.
- This may be a tall order.
-
-- Integrate local-time with http://common-lisp.net/project/cl-l10n/
- Also drop time/timezone related functionality from cl-l10n.
-
-- Make local-time work with olson timezone rules
- http://www.twinsun.com/tz/tz-link.htm
- Right now, we're using zic compiled files, which have a limited
- scope. They may also be larger than the corresponding rule files.
-
-- Support timespecs
-
-******
-
-Attila: i think we identified a bit of confusion in the code which
-i'll try to sum up here.
-
-first of all many of the operations currently defined on timestamps
-should not really be defined on timestamps at all. i think this is due
-to some heritage from the times when a timestamp value also had a
-timezone value attached to it.
-
-examples of such bogus operations are timestamp+, timestamp-, all
-adjust-timestamp variants that operate on the components of a date
-value, etc.
-
-let's define the nomenclature first:
-------------------------------------
-
- - timestamp: a value representing a sharp cut on the continuous t
-axis (as in physics) of time, and as that it is mostly unrelated to
-timezones and different calendar systems (e.g. Julian, Gregorian),
-which are just ways to denote a timestamp in a way humans can easily
-deal with.
-
- - calendar system: a method defining how to denote a timestamp using
-a set of numbers (called year, month, day, etc). there are various
-such encodings like the Gregorian calendar, or the Julian calendar
-(which was in effect in Russia until 1922!). wikipedia has loads of
-info about these.
-
- - date: tightly coupled with a calendar system. it contains the
-fields defined by the calendar system, some of them may be
-undefined. note that this is a bit more flexible than what the
-everyday usage of the word 'date' suggests. so i'm open for
-alternative names! java calls them as 'calendar', which is not
-completely nuts if you think of it as a paper calendar with a movable
-current date marker hanging on the wall.
-
-operations defined on timestamps:
----------------------------------
-
- - do basic arithmetic with them, essentially arithmetic on numbers
-denoting seconds. operations that would expose the epoch chosen by the
-implementation are not allowed (e.g. adding two timestamps), but
-things like adding/subbing literals and substracting two timestamps
-are valid.
-
- - convert to/from date (only in the mandatory context of a calendar
-system, which most of the time includes a timezone, too.)
-
-operations defined on dates:
-----------------------------
-
- - parse from string representation, e.g. an rfc3339 string. note that
-such a timestring does not necessarily describe a timestamp
-completely. it only does so when it contains all the components needed
-by the calendar system to denote a sharp cut on the t axis.
-
- - set/offset any component of it, although what those operations mean
-potentially depend on the calendar system and its parameters (e.g. the
-optional timezone value in it). also note that some operations are
-potentially undefined and signal an error with certain illegal values
-(e.g. instantiating a date using an illegal or contradictory
-combination of its parameters; setting a field to an illegal value
-like february 29 in leap years...)
-
- - convert to/from a timestamp (strictly in the context of a calendar
-system and a timezone)
View
99 TODO.org
@@ -0,0 +1,99 @@
+* Basic Outline
+** A more human friendly parser
+
+ PARSE-TIMESTRING works fine, but we need a more human-friendly parser that
+ can handle stuff like "08/03/2006 1:54pm CST". or maybe not? see
+ http://chaitanyagupta.com/lisp/chronicity/
+
+** Support for other notational systems than the Gregorian
+
+** Ideally, local-time should have everything that the ruby Date class does
+
+ Also, the time functions in the venerable and honored clsql library.
+ This may be a tall order.
+
+** Integrate local-time with http://common-lisp.net/project/cl-l10n/
+ Also drop time/timezone related functionality from cl-l10n.
+
+** Make local-time work with olson timezone rules
+ http://www.twinsun.com/tz/tz-link.htm
+ Right now, we're using zic compiled files, which have a limited
+ scope. They may also be larger than the corresponding rule files.
+
+* Attila:
+Many of the operations currently defined on timestamps should not
+really be defined on timestamps at all. i think this is due to some
+heritage from the times when a timestamp value also had a timezone
+value attached to it.
+
+Examples of such bogus operations are timestamp+, timestamp-, all
+adjust-timestamp variants that operate on the components of a date
+value, etc.
+
+* Nomenclature
+** timestamp: a sharp cut on the continuous t axis (as in physics) of time
+ It is mostly unrelated to timezones and different calendar systems
+ (e.g. Julian, Gregorian), which are just ways to denote a timestamp in
+ a way humans can easily deal with.
+
+** interval: a range on the time axis denoted by two timestamps
+
+** date-time: contains the fields defined by the calendar system
+ Some date-time fields may be left undefined.
+
+** calendar: a converter to and from a particular date-time type
+ A method defining how to denote a timestamp using a set of numbers
+ (called year, month, day, etc). there are various such encodings
+ like the Gregorian calendar, or the Julian calendar (which was in
+ effect in Russia until 1922!). wikipedia has loads of info about
+ these. We'll default to a naive Gregorian calendar
+
+** duration: a value representing a delta between date-times
+
+
+* Timestamp Operations
+** basic arithmetic
+ essentially arithmetic on numbers denoting seconds. operations that
+ would expose the epoch chosen by the implementation are not allowed
+ (e.g. adding two timestamps), but things like adding/subbing
+ literals and substracting two timestamps are valid.
+
+** convert to/from date
+ (only in the mandatory context of a calendar system, which most of
+ the time includes a timezone, too.)
+
+** create an interval given two timestamps
+
+** comparison predicates
+
+* Interval Operations
+** Arithmetic with timestamps
+** Arithmetic with intervals
+** convert to a duration with a calendar
+** Intersection with a timestamp
+** Overlap with another intervals
+
+* Date-time operations
+** parse from string representation
+ , e.g. an rfc3339 string. note that such a date-time does not
+ necessarily describe a timestamp completely. it only does so when
+ it contains all the components needed by the calendar system to
+ denote a sharp cut on the t axis.
+
+** set/offset any component of it,
+ although what those operations mean potentially depend on the
+ calendar system and its parameters (e.g. the optional timezone
+ value in it). also note that some operations are potentially
+ undefined and signal an error with certain illegal values
+ (e.g. instantiating a date using an illegal or contradictory
+ combination of its parameters; setting a field to an illegal value
+ like february 29 in leap years...)
+
+** convert to/from a timestamp
+ (strictly in the context of a calendar system and a timezone)
+
+** comparison functions
+
+* Duration operations
+** Arithmetic with date-times
+** Arithmetic with durations

0 comments on commit da17285

Please sign in to comment.
Something went wrong with that request. Please try again.