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.
