otaylor at redhat.com
Sun Jul 20 05:17:12 EEST 2003
On Sat, 2003-07-19 at 16:12, Tuomas Kuosmanen wrote:
> On Sat, 2003-07-19 at 22:12, Matthias Clasen wrote:
> > 2) Is the proposed format good enough, or should we optionally include
> > time information ?
> I am clueless on these things, but how about the unix time stamp string?
> That includes the exact time, and one could use it as "time" or "date"
> depending on the application..?
A unix time value (seconds since epoch) identifies a particular point
in time. It doesn't actually give you a unique calendar date without
specifying the the time zone. It's 1058664797 now, which is
2003-07-19 here, but 2003-07-20 there.
A date, as a year/month/day triplet is pretty much an artificial
construct, but pretty much universally used in practice.
One issue that needs to be decided is the interpretation of the
dates with respect to the Julian/Gregorian calendar switch.
- "Proleptic Gregorian" - you assume that the Gregorian calendar
extends back in time indefinitely - SQL DATE, GDate, etc, work
- Interpret dates according to the rules of the time - this is
pretty much impossible to do right because the Julian/Gregorian
switch was different for different countries.
- Say that the DND data type is just the year-month-day triplet
as displayed to the user, so if you have one app displaying
Julian calendar dates, and one program displaying proleptic
Gregorian dates, and you drag 'May 29, 1453', you get
'May 29, 1453' not 'June 7, 1453'.
While the last may seem conceptually wrong, it does have the
advantages of being easy to implement, easy to understand for
the user, and of handling the case where the programmer has no
idea what sort of date they are displaying.
(Luckily, handling of dates from 300 years ago is somewhat
More information about the xdg