2015-08-11 0:37 GMT+03:00 David Jarvie :
> On Mon, August 10, 2015 11:31 am, Dāvis Mosāns wrote:
>> 2015-08-10 11:34 GMT+03:00 John Layt :
>>> On 9 August 2015 at 17:26, Dāvis Mosāns wrote:
When I implement date/time related things I always use timestamps in
UTC everywhere
On Mon, August 10, 2015 11:31 am, DÄvis MosÄns wrote:
> 2015-08-10 11:34 GMT+03:00 John Layt :
>> On 9 August 2015 at 17:26, DÄvis MosÄns wrote:
>>>
>>>
>>> When I implement date/time related things I always use timestamps in
>>> UTC everywhere
>>> and when need to display to user or pass to s
2015-08-10 11:34 GMT+03:00 John Layt :
> On 9 August 2015 at 17:26, Dāvis Mosāns wrote:
>>
>>
>> When I implement date/time related things I always use timestamps in
>> UTC everywhere
>> and when need to display to user or pass to some API then convert to
>> respective
>> format and timezone. Any
On 9 August 2015 at 17:26, Dāvis Mosāns wrote:
>
> When I implement date/time related things I always use timestamps in
> UTC everywhere
> and when need to display to user or pass to some API then convert to
> respective
> format and timezone. Any other way makes it only more complicated.
>
That
On Monday, August 03, 2015 14:59:59 Dāvis Mosāns wrote:
> Sorry for injecting myself, but IMO there's no such thing as Date-only and
> what you need is something like QDateTimeRange (just made up) where you
> would have start QDateTime, end QDateTime and it could represent any
> Event/Interval. Lik
2015-08-09 17:54 GMT+03:00 Sergio Martins :
> On Monday, August 03, 2015 14:59:59 Dāvis Mosāns wrote:
>> Sorry for injecting myself, but IMO there's no such thing as Date-only and
>> what you need is something like QDateTimeRange (just made up) where you
>> would have start QDateTime, end QDateTime
On Tuesday, August 04, 2015 14:48:02 John Layt wrote:
> On 4 August 2015 at 10:45, John Layt wrote:
> > Most of this discussion is very very off-topic, it belongs on the Qt
> > development list, can we get back to the main topic of KCalCore and
> > QDateTime? I have limited time to spare and I'd r
2015-08-03 20:09 GMT+03:00 Martin Klapetek :
> On Mon, Aug 3, 2015 at 6:34 PM, Thiago Macieira wrote:
>>
>> On Monday 03 August 2015 08:33:54 Martin Klapetek wrote:
>> > > If the format you're looking for requires support from translators,
>> > > please
>> > > add
>> > > a new class to QtCore.
>>
2015-08-03 17:33 GMT+03:00 David Jarvie :
> On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote:
>
>> 2015-08-03 15:26 GMT+03:00 David Jarvie :
>
>> > On Monday 03 Aug 2015 12:59:59 you wrote:
>
>> >
>
>> >> 2015-08-02 21:32 GMT+03:00 David Jarvie :
>
>> >
>
>> >> >
>
>> >
>
>> >> > Date-only KDateTi
2015-08-03 15:26 GMT+03:00 David Jarvie :
> On Monday 03 Aug 2015 12:59:59 you wrote:
>
>> 2015-08-02 21:32 GMT+03:00 David Jarvie :
>
>> >
>
>> > Date-only KDateTime instances are not only used for Event start/end
>
>> > timestamps. In KAlarm they are also used among other things for alarm
>> > sn
2015-08-02 21:32 GMT+03:00 David Jarvie :
>
> Date-only KDateTime instances are not only used for Event start/end
> timestamps. In KAlarm they are also used among other things for alarm snooze
> times (independently of whether the event is date-only or not). So usage of
> the date-only attribute is
Hey John,
> OK, I had a quick look at this and to do it in Qt and it wasn't actually
> that hard. You can see the result at:
>
> https://codereview.qt-project.org/#/c/122750/
>
> This should support the full set of VTIMEZONE rules, have a look and let me
> know if not.
>
> I'm not sure if it wi
On 2 August 2015 at 14:26, John Layt wrote:
> On 1 August 2015 at 19:47, Sandro Knauß wrote:
>
> > * indivual timezone support, this is something that we need when parsing
> ical
> > and have no known timezone information. I havn't looked into it, but I
> think
> > this can make it eventually in
On Tuesday 04 August 2015 10:03:20 John Layt wrote:
> Nor do we want to use the data in the POSIX file as it
> has too many shortcomings and lacks features and simply uses a
> different set of format codes to CLDR. That POSIX file can only ever
> really be used to tell non-Qt POSIX locale using app
On Tuesday 04 August 2015 10:03:20 John Layt wrote:
> > One problem would be to update running processes (QLocale to track the
> > locale file and emit some signal on changes)
>
> This is one of the areas Qt doesn't do well, on Windows and Mac soon
> as the underlying locale is change you get diff
On 4 August 2015 at 10:45, John Layt wrote:
> Most of this discussion is very very off-topic, it belongs on the Qt
> development list, can we get back to the main topic of KCalCore and
> QDateTime? I have limited time to spare and I'd rather use it to solve
> the immediate problems that we can fi
On 4 August 2015 at 03:03, Thiago Macieira wrote:
> On Monday 03 August 2015 21:57:36 John Layt wrote:
>> The problem actually is that Plasma is not considered a system
>> platform by QLocale, it doesn't go looking for what Plasma wants, it
>> just uses the underlying GNU/Linux system settings. Co
On 4 August 2015 at 09:11, Thomas Lübking wrote:
> On Montag, 3. August 2015 23:17:04 CEST, John Layt wrote:
>
>> Not nonsense, exactly my long-term plan to get Gtk and other apps to
>> use the right Plasma locale settings when running under Plasma. It
>> 'just' requires the kcm to learn how to wr
On Montag, 3. August 2015 23:17:04 CEST, John Layt wrote:
Not nonsense, exactly my long-term plan to get Gtk and other apps to
use the right Plasma locale settings when running under Plasma. It
'just' requires the kcm to learn how to write and compile a POSIX
locale file.
That actually doesn't
On Tuesday 04 August 2015 17:52:18 Ben Cooksley wrote:
> I'm assuming QLocale isn't routed through the platform plugin like
> other parts of Qt do in these cases, so we can't manipulate things
> there?
Right.
If a LC_TIME solution isn't possible, we could consider a QSystemLocale
configuration t
On Tue, Aug 4, 2015 at 8:57 AM, John Layt wrote:
> On 3 August 2015 at 07:33, Martin Klapetek wrote:
>
>> So what is missing/wanted is telling QLocale to use en_GB *but* return
>> any time string in 24h format for example. Or to use ISO date format
>> by default. The stuff coming from cldr might
On Monday 03 August 2015 22:00:04 John Layt wrote:
> On 3 August 2015 at 20:07, David Jarvie wrote:
> > As I understand it, a QDateTime is invalid if either the date or time
> > component is invalid. People would usually expect that if
> > QDateTime::isValid() returns false, the object must be inv
On Monday 03 August 2015 21:57:36 John Layt wrote:
> The problem actually is that Plasma is not considered a system
> platform by QLocale, it doesn't go looking for what Plasma wants, it
> just uses the underlying GNU/Linux system settings. Convince Qt to
> hard-code in a lookup of some Plasma conf
On Monday 03 August 2015 22:15:51 John Layt wrote:
> One problem is Qt completely ignores the contents of that file, and
> indeed I'm not sure it would even manage to extract the correct locale
> name even so you'd end up with some default.
We just need to fix QSystemLocale and make it fall back t
On 3 August 2015 at 19:58, David Jarvie wrote:
> There are a number of cases in kdepim where a date-time or a date can be
> supplied. Using KDateTime makes the code cleaner - there is no need to
> provide overloads or to track whether it's date-only when calling multiple
> layers of functions or
[Again resend from subscribed account, damn gmail!]
On 3 August 2015 at 19:03, Thomas Lübking wrote:
> Disclaimer: I may talk nonsense.
>
> What about exporting LC_TIME=KDE and have a ~/.local/share/i18n/locales/KDE
> which can be configured from the locale kcm.
>
> This way *all* applications (
On 3 August 2015 at 19:03, Thomas Lübking wrote:
> Disclaimer: I may talk nonsense.
>
> What about exporting LC_TIME=KDE and have a ~/.local/share/i18n/locales/KDE
> which can be configured from the locale kcm.
>
> This way *all* applications (including even mc ;-) would follow the pattern
> the
On 3 August 2015 at 20:07, David Jarvie wrote:
> As I understand it, a QDateTime is invalid if either the date or time
> component is invalid. People would usually expect that if
> QDateTime::isValid() returns false, the object must be invalid. So a
> date-only value in which only the date was va
On 3 August 2015 at 07:33, Martin Klapetek wrote:
> So what is missing/wanted is telling QLocale to use en_GB *but* return
> any time string in 24h format for example. Or to use ISO date format
> by default. The stuff coming from cldr might not always be what
> the user wants. And there's no easy
On 2 August 2015 at 19:32, David Jarvie wrote:
> Having a date-only attribute in KDateTime is very useful because it allows
> both date-time and date-only values to be encapsulated in a single class.
> This avoids having to be able to pass either a QDate or QDateTime or to have
> a separate flag e
[Reply sent again from subscribed account]
On 2 August 2015 at 16:08, Martin Klapetek wrote:
> On Sun, Aug 2, 2015 at 3:26 PM, John Layt wrote:
Yes, KLocale was in many ways the best localization library around, I
and others worked hard to make it that good, but ultimately it's one
that lost be
On 2 August 2015 at 16:08, Martin Klapetek wrote:
> On Sun, Aug 2, 2015 at 3:26 PM, John Layt wrote:
Yes, KLocale was in many ways the best localization library around, I
and others worked hard to make it that good, but ultimately it's one
that lost because it made KDE a walled garden and failed
On Monday 03 Aug 2015 19:49:52 Thomas Lübking wrote:
> On Sonntag, 2. August 2015 20:32:43 CEST, David Jarvie wrote:
>
> > Having a date-only attribute in KDateTime is very useful
> > because it allows both date-time and date-only values to be
> > encapsulated in a single class. This avoids havi
On Monday 03 Aug 2015 18:22:28 you wrote:
> 2015-08-03 17:33 GMT+03:00 David Jarvie :
> > On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote:
> >
> >> 2015-08-03 15:26 GMT+03:00 David Jarvie :
> >
> >> > On Monday 03 Aug 2015 12:59:59 you wrote:
> >
> >> >
> >
> >> >> 2015-08-02 21:32 GMT+03:00 Davi
On Sonntag, 2. August 2015 20:32:43 CEST, David Jarvie wrote:
Having a date-only attribute in KDateTime is very useful
because it allows both date-time and date-only values to be
encapsulated in a single class. This avoids having to be able to
pass either a QDate or QDateTime or to have a sepa
On Montag, 3. August 2015 19:09:17 CEST, Martin Klapetek wrote:
Setting different LC_TIME values proven to not be feasible, because
very often users want "just" 24h clock format _and_ their locale's
date format. Or some date format and their locale's time format.
Disclaimer: I may talk nonsens
On Mon, Aug 3, 2015 at 6:34 PM, Thiago Macieira wrote:
> On Monday 03 August 2015 08:33:54 Martin Klapetek wrote:
> > > If the format you're looking for requires support from translators,
> please
> > > add
> > > a new class to QtCore.
> >
> > Suppose there's such QLocale setting as described abo
On Monday 03 August 2015 08:33:54 Martin Klapetek wrote:
> > If the format you're looking for requires support from translators, please
> > add
> > a new class to QtCore.
>
> Suppose there's such QLocale setting as described above, then it would
> be just a matter of some regexp inside the time fo
On Monday 03 Aug 2015 14:29:41 Dāvis Mosāns wrote:
> 2015-08-03 15:26 GMT+03:00 David Jarvie :
> > On Monday 03 Aug 2015 12:59:59 you wrote:
> >
> >> 2015-08-02 21:32 GMT+03:00 David Jarvie :
> >
> >> >
> >
> >> > Date-only KDateTime instances are not only used for Event start/end
> >> > timestamps
On Monday 03 Aug 2015 12:59:59 you wrote:
> 2015-08-02 21:32 GMT+03:00 David Jarvie :
> >
> > Date-only KDateTime instances are not only used for Event start/end
> > timestamps. In KAlarm they are also used among other things for alarm snooze
> > times (independently of whether the event is date-on
On Sun, Aug 2, 2015 at 7:36 PM, Thiago Macieira wrote:
> If the format you're looking for is in the CLDR, you're welcome to add the
> support to QLocale.
>
It's not really about any missing locale, it's about setting different
parameters
for the given locale. For example David Edmundson (a brit)
On Sunday 02 Aug 2015 14:26:18 John Layt wrote:
> On 1 August 2015 at 19:47, Sandro Knauß wrote:
>
> > * dateOnly support is used a lot. In ICAL it differs if you set dateonly or
> > datetime. dateonly events f.ex. lasts a day without timezone info f.ex. "New
> > Year" is a dateonly event that la
On Sunday 02 August 2015 17:08:04 Martin Klapetek wrote:
> On Sun, Aug 2, 2015 at 3:26 PM, John Layt wrote:
> > If you do this you also need all of KLocale again which we also
> > do not want. Don't even go there, we changed it for a purpose.
>
> Fwiw, over the year(s) of Plasma5, many times it w
On Sun, Aug 2, 2015 at 3:26 PM, John Layt wrote:
> If you do this you also need all of KLocale again which we also
> do not want. Don't even go there, we changed it for a purpose.
>
Fwiw, over the year(s) of Plasma5, many times it was expressed
that KLocale is greatly missed, especially when it
On 1 August 2015 at 19:47, Sandro Knauß wrote:
> * indivual timezone support, this is something that we need when parsing ical
> and have no known timezone information. I havn't looked into it, but I think
> this can make it eventually into QDateTime.
This is the real problem and the biggest stu
On Saturday 01 August 2015 20:47:16 Sandro Knauß wrote:
> Hello,
>
> the kdepim is discussing how we can replace KDateTime inside kdepim
> (primarly kcalcore) . There are some issues, why we can't replace it simply
> with QDateTime.
>
> * indivual timezone support, this is something that we need
Hello,
the kdepim is discussing how we can replace KDateTime inside kdepim (primarly
kcalcore) . There are some issues, why we can't replace it simply with
QDateTime.
* indivual timezone support, this is something that we need when parsing ical
and have no known timezone information. I havn't
47 matches
Mail list logo
