Date or Date-and-time for transactions

[John Ralls]

On Nov 29, 2012, at 6:21 AM, Derek Atkins <warlord at MIT.EDU> wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>>> Agreed, a Post Date should be a "Date".  There is an open RFE from about
>>> a decade ago to allow a "Post Time", but that's never really been
>>> implemented and opens a large can of worms (which, honestly, has already
>>> been opened).
>>> 
>> I don't think Post Date is really an issue here: It's a user-entered
>> date, and if its internal representation is a GDate, then there is no
>> timezone issue if we also get rid of the timezone-aware code. Then we
>> can also get rid of all of the gyrations to set dates to the
>> beginning, middle, or end of the day. I'm all for using GDates for the
>> internal representation of dates with one caveat: We have to avoid
>> g_date_set_time(), g_date_set_time_t(), and even g_date_set_timeval(),
>> because they all use a 32-bit time_t. Not a big deal, just create the
>> GDate from a GDateTime.
>> 
>> Entry date-time is another matter, particularly in a multi-user,
>> multi-timezone case. Since it's used mostly for sorting, maybe we
>> should just leave it in Z and ignore timezone altogether. That would
>> simplify a lot of code.
> 
> As you say, the dates are stored as ISO8601, or converted from local
> time to UTC.  So I think even in a multi-user environment we're fine,
> because datetimes will either have a local timezone or be converted to
> UTC and therefore end up in the correct order.

Right. Since ISO8601 specifies that date-times are converted to UTC (Z), we currently convert to-and-from the local TZ when we instantiate objects with a Timespec field. I'm saying we should stop doing that and just use UTC for timestamps. This has the added benefit of making unnecessary the GTimeZone workarounds for MSWin, all of the messiness associated with DST, and a boatload of code.

> 
>>> IMHO the Post Date should be an actual Date, and not a Timespec.  But
>>> changing the data format is -- challenging.  ;)
>> 
>> Actually, the stored date format is an ISO8601 date-time string, so we
>> can do whatever we want for an internal representation.
> 
> The issue is semantics.  How do we know whether a data file is using the
> old interpretation or the new interpretation of a timestamp for the Post
> Date?

ATM, we store YYYY-MM-DD 12:00:00Z. For backwards compatibility, I suppose we should continue to do so.  The change will be that internally we'll just make a GDate from it.