How to design date/time libraries (was: Arbitrary abbreviations in phobos considered ridiculous)

[Stewart Gordon]

On 08/03/2012 02:56, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
>> On 07/03/2012 08:10, Jacob Carlborg wrote:
>> <snip>
>>
>>> Yeah, Clock.now() would be good and Data.today() as well.
>>
>> My utility library has, for consistency, DateValue.now, TimeValue.now and
>> DateTime.now.
>
> I specically avoided giving a way to get the time with any type other than
> SysTime (and TickDuration for using a monotonic clock), because I believe that
> it leads to incorrect behavior. Any time that you're dealing with the system
> clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are
> for when you need the date and/or time but don't care about what absolute time
> it's associated with in the real world.  Treating DateTime as corresponding to
> a specific point in time is just going to cause problems, because it has no
> time zone.
<snip>

TimeValue and DateTime in my library always store the time in UTC.  It uses a global 
variable for time zone.  But a LocalTime could be added to the mix.  This would be used to 
hold a time that, when combined with a date, will become a DateTime set according to the 
correct time zone.

Interestingly, SQL has

DATE - just a date, simple as that
TIME - a time of day in unspecified time zone
TIMETZ - a time of day with time zone specified
TIMESTAMP - a date/time combination in unspecified time zone
TIMESTAMPTZ - an absolute instant in time, which can be constructed and examined according 
to the system time zone

Notice how different TIMETZ and TIMESTAMPTZ are, even though "TZ" abbreviates " WITH TIME 
ZONE" in both cases.  Moreover, system time zones (in at least some SQL implementations) 
include DST rules, whereas the zone stored in a TIMETZ is just a UTC offset.

In my scheme:
- DateValue corresponds to DATE
- TimeValue corresponds to a TIMETZ with the zone set as UTC
- DateTime corresponds to TIMESTAMPTZ
- LocalTime, if it were added, would correspond to TIME

I'd also like to add DST handling to my library, but it'll take thinking about.  I'm not 
sure what OS APIs have in the way of retrieving the DST rules for the locale.  Though I 
have just discovered GetDynamicTimeZoneInformation in the Windows API - I'll investigate 
it later.

Stewart.