Calendar Types

[Seth Kurtzberg]

Bayley, Alistair wrote:

>>From: Ashley Yakeley [mailto:ashley at semantic.org] 
>>
>>* Should we include a timezone field in CalendarTime?
>>    
>>
>
>Yes. If a CalendarTime doesn't carry timezone information with it, then the
>user must bundle it. They will want to do this because (1) they will be
>probably dealing with local time (2) a CalendarTime sans timezone is
>equivalent to UTC, and is therefore not much use (i.e. we may as well use
>UTC instead).
>
>
>  
>
>>* TimeZone represents a fixed offset to UTC. What should it look like 
>>internally, and what functions on it should we provide?
>>    
>>
>
>There are timezones which are not integral hour offsets, so an (hours,
>minutes) pair, or maybe just ticks is sufficient. Or maybe a Duration (see
>below). Ticks is probably best from an implementation point-of-view, right?
>  
>
For example, New Delhi is on the half hour when time here is on the 
hour.  I'm not sure whether that is part of a daylight savings scheme or 
not.

Certainly ticks has the granularity to represent any fixed offset.

>Should it include the timezone name? Although the name determines the
>offset, a given offset could match many names, so to preserve information
>we'd probably want to retain the timezone name internally. Do we want to
>support timezone names?
>
>Do we want to embed summer-time (daylight-savings) timezone behaviour into
>the library? This would obviously be useful for displaying the correct local
>time, but makes the timezone part of the library quite complex.
>  
>
There are many details which are not easy to represent with a timezone.  
There are places (e.g. in Indiana) where a town just over the timezone 
line from another town uses the "wrong" timezone, in that case to handle 
the problem that the towns have grown to the point where they are 
actually one (virtual?) town.

Arizona does not observe daylight savings time, but on some of the 
Indian reservations daylight savings is observed.

The state of Sonora, in Mexico, makes a decision periodically to follow, 
or not follow, the fact that Arizona (its northern neighbor) doesn't use 
daylight savings, but other Mexican states in the same time zone do 
observe daylight savings.  In the last ten years I know that the 
decision has changed twice, and currently Sonora follows the practice of 
other Mexican states in the same time zone.

So, a time zone, at least one based on geographical location, isn't 
sufficient.  Accounting for daylight savings doesn't cover every case 
either; I gave a couple of examples but doubtless there are many others 
I don't know about.

You can still represent them in terms of an offset, but your information 
becomes stale, and the time zone name, or the time returned by 
localtime, isn't necessarily the local time.  (A bizarre but true 
statement).

Most operating systems, at least as delivered, don't have any way to 
handle variations other than daylight savings.  There is no way to 
override the boundaries of a time zone.  In most cases you could correct 
this by adding a new time zone, but I wouldn't want to try this in windows.

I think the only way to handle it is with an argument that allows the 
user to override the offset that the machine itself uses.  That's ugly, 
and you would have Haskell returning a different time than the 
localtime() library call.  You can argue that it is better to be 
accurate, but you can also argue that issues will arise.  A program 
might be using FFI and thus one part of the program potentially would 
have a different value for the local time than another part.

Also it is an invitation to make a mistake, by either forgetting to use 
the signature that allows application of a user correction, or not using 
the same offset for each call.

All the possible solutions are (IMHO) unacceptable.  So I guess you have 
to choose which is the least unacceptable.

>
>  
>
>>OK, so here are the basic functions of System.Time.Calendar:
>>
>>  utcToCalendar :: TimeZone -> UTCTime -> CalendarTime
>>
>>  calendarToUTC :: TimeZone -> CalendarTime -> UTCTime
>>
>>CalendarTime should be a "struct", i.e. a datatype with its 
>>constructor and access functions exported.
>>    
>>
>
>
>I'm assuming System.Time.Calendar is Gregorian. How about
> - a Duration type
> - some calendar arithmetic functions
> - arithmetic on Durations
>
>e.g.
>
>  data Duration = Duration
>  {
>    -- this looks familiar...
>    durYear    :: Int,
>    durMonth   :: Int,
>    durDay     :: Int,
>    durHour    :: Int,
>    durMin     :: Int,
>    durSec     :: Int,
>    durPicosec :: Integer
>  } deriving ...
>
>
>  calendarAdd :: CalendarTime -> Duration -> CalendarTime
>  calendarDiff :: CalendarTime -> CalendarTime -> Duration
>  durationAdd :: Duration -> Duration -> Duration
>  durationDiff :: Duration -> Duration -> Duration
>
>
>Alistair.
>
>-----------------------------------------
>*****************************************************************
>Confidentiality Note: The information contained in this   message, and any
>attachments, may contain confidential   and/or privileged material. It is
>intended solely for the   person(s) or entity to which it is addressed. Any
>review,   retransmission, dissemination, or taking of any action in
>reliance upon this information by persons or entities other   than the
>intended recipient(s) is prohibited. If you received  this in error, please
>contact the sender and delete the   material from any computer.
>*****************************************************************
>
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries
>
>!DSPAM:42108ad5163345519714160!
>
>  
>