https://bugs.freedesktop.org/show_bug.cgi?id=67763
Priority: medium
Bug ID: 67763
Assignee: [email protected]
Summary: date & time controls: fractional seconds, timezone
support, duration, interval
Severity: enhancement
Classification: Unclassified
OS: All
Reporter: [email protected]
Hardware: All
Status: NEW
Version: unspecified
Component: Libreoffice
Product: LibreOffice
In 4.1, we changed our dat&time-related API datatypes to support:
- negative year
- nanosecond resolution
- timezone
The next step is to update our UI elements to support these new features,
as well as introduce UI elements for durations and intervals.
Negative year
=============
Need to decide if negative years are meant astronomically (that is,
before year 1 is year 0) or traditionally (that is, before year 1 is
year -1).
Our code calling OS libraries (in sal/osl/) possibly to be adapted.
Test whether our date formatting is prepared for negative values.
Nanosecond precision
====================
We have two ways to display a timestamp (datetime):
1) "formatted field" with a date format; it works with concepts
inherited from spreadsheets, namely that everything is a double
(floating-point number); dates are a number of days since an epoch
in the late 19th or early 20th century.
These can already do "arbitrary precision" formatting of timestamps
with a user-defined format ("just" add ".#########" to the end of
the format), but the "double" floating-point precision is not
adequate for full nanosecond resolution, and behaves weirdly anyway
in that the available precision depends on the distance of the date
from the epoch. For the commonest example of dates in the late20th
/ early 21st century, the value of the double is around 4E4
( = 4*10^4 = 40000).
The mantissa has 53 bits of precision; getting to seconds precision
takes about 32 bits, leaving about 20 bits for the fractional
seconds. This around to a precision of the order of magnitude of
microseconds.
But dates within a few days of the epoch have a "full" nanosecond
precision (and beyond) ;)
2) Dedicated "time" and "date" fields, but no single "timestamp"
control. In base (forms), splitting a datetime into its date and
time components works (there is special support code for that; each
control will "touch" only its part of the timestamp).
Wrt 1, we could extend formatted fields to quad floating-point
precision, but IMHO that's just adding to the hackish approach. Unless
Calc decides to do it for its own reasons, I don't think it would be
worth it.
Wrt 2, we need to add cases to
offapi/com/sun/star/text/TimeDisplayFormat.idl for higher
precision. Which ones? Maybe one each for milli, micro and
nanoseconds (times two, for 24-hours and AM/PM variants)?
The implementation is in:
xmloff/source/forms/handler/vcl_time_handler.*
(conversion between XML attributes and our internal datatypes)
include/toolkit/controls/unocontrols.hxx
include/toolkit/controls/unocontrolbase.hxx
include/toolkit/controls/unocontrolmodel.hxx
toolkit/source/controls/unocontrolbase.cxx
toolkit/source/controls/unocontrolmodel.cxx
toolkit/source/controls/unocontrols.cxx
(classes UnoControlTimeFieldModel, UnoTimeFieldControl)
include/toolkit/awt/vclxwindows.hxx
toolkit/source/awt/vclxwindows.cxx
(class class VCLXTimeField)
include/vcl/field.hxx
vcl/source/control/field2.cxx
(classes TimeFormatter, TimeField, TimeBox)
forms/source/component/Time.*
(classes OTimeControl, OTimeModel)
svx/source/fmcomp/gridcell.cxx
(class DbTimeField)
commit 43ea97e1f9cecd6c7cba8db35ce1307c858c6857
Author: Lionel Elie Mamane <[email protected]>
Date: Sun Jul 28 16:08:26 2013 +0200
fdo#67235 adapt form control code to time nanosecond API change
gives a good overview of the kind of things that need to change.
Timezones
=========
Something like:
1) Add a property "which timezone should the the display be in".
(Can be "none" which is different than 0.)
2) Add a property "assume that untimezoned data from the database is
in timezone XXX".
3) Handle conversions in the code.
Do we also want an option "show timezone explicitly"? That would IMO
probably be in a different control, not a setting of the existing
control.
For timestamps, it makes the split in date and time more complicated
(because the timezone can impact both the date and the time), but
possibly still workable. We could also introduce a "datetime" control,
which would IMHO be cleaner / nicer.
What is a timezone in the new property? For isolated times, I think
only "fixed offset to UTC" make sense, and maybe a few special values
like "SYSTEM". But for full datetime, the user would like to enter
something like a city, and have the timezone at that date in the city,
taking into account daylight-saving time and everything. Which
introduces the parsing ambiguity of one hour when going from DST to
winter time...
How to implement that? Ship a copy of the IANA Olson / tz / zoneinfo
database? Rely on the one from the system?
For date-related code, take the list of files and classes above and
replace "Time" by "Date".
Durations and Intervals
=======================
Duration = length of time (e.g. 3 days, 2 hours, 5 minutes and 30s)
Interval = one start datetime and one end datetime
(e.g. from 4 may 2013 8:00:00 o'clock to 7 september 2013 18:00:00)
isomorphic to datetime+duration
Take inspiration of our date&time controls to make duration control
and interval control.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
