I'm in the process of refactoring the corelib's Date class, and would like
to get some feedback on this.
The idea is to make it easier to use for the general case, and *not*
implement a feature complete Date library. We eventually need something
like Java's Joda library, but such a library would be way too big for the
corelib and would confuse most people (Dates, DateTimes, and TimeZones are
unfortunately pretty complicated...).
As a first step I want to do the modifications I propose in CL
https://chromiumcodereview.appspot.com/10384149 That is: remove the TimeZone class, make Date hashable, add optional
arguments to the constructor and add a way to get to the TimeZone(offset).
The biggest change in the CL is that it would not be possible to get to the
UTC fields anymore. There would be a toUTCString() but no utcMonth (or any
other getter).
The reasoning is that timezone-independent operations almost always only
want the epoch-time (which is accessible through the 'value' field), or
print it (for logging). Both use-cases are still covered.
The following bugs would be obsolete if I go ahead with my changes:
TimeZone utc/local constructors should be constants: http://dartbug.com/2581 DateImplementation doesn't check for required timezone argument:
http://dartbug.com/1260
I also propose closing http://dartbug.com/1424 (Split into Date and
TimeStamp). This is outside the scope of the corelib.
And since I start the discussion on Dates we should maybe also look at
adding support for some other epochs:
http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_epoch_dat... Personally I don't see any good candidate, but I remember vaguely that at
least one of those is commonly used. But that could be bad memory...
We should also consider:
Rename the time getters (d.hours -> d.hour, d.minutes -> d.minute, ...):
http://dartbug.com/1985
// florian
-- Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett
Something I often need is the equivalent of Date.fromEpoch but with
human-readable arguments. Otherwise I keep going to
http://www.epochconverter.com/ and I put the human-readable UTC date in a
comment next to the timestamp. It doesn't add any expressivity, just
readability.
Paul
On Mon, May 14, 2012 at 3:59 PM, Florian Loitsch <floit...@google.com>wrote:
> I'm in the process of refactoring the corelib's Date class, and would like
> to get some feedback on this.
> The idea is to make it easier to use for the general case, and *not*
> implement a feature complete Date library. We eventually need something
> like Java's Joda library, but such a library would be way too big for the
> corelib and would confuse most people (Dates, DateTimes, and TimeZones are
> unfortunately pretty complicated...).
> As a first step I want to do the modifications I propose in CL
> https://chromiumcodereview.appspot.com/10384149 > That is: remove the TimeZone class, make Date hashable, add optional
> arguments to the constructor and add a way to get to the TimeZone(offset).
> The biggest change in the CL is that it would not be possible to get to
> the UTC fields anymore. There would be a toUTCString() but no utcMonth (or
> any other getter).
> The reasoning is that timezone-independent operations almost always only
> want the epoch-time (which is accessible through the 'value' field), or
> print it (for logging). Both use-cases are still covered.
> The following bugs would be obsolete if I go ahead with my changes:
> TimeZone utc/local constructors should be constants:
> http://dartbug.com/2581 > DateImplementation doesn't check for required timezone argument:
> http://dartbug.com/1260
> I also propose closing http://dartbug.com/1424 (Split into Date and
> TimeStamp). This is outside the scope of the corelib.
> And since I start the discussion on Dates we should maybe also look at
> adding support for some other epochs:
> We should also consider:
> Rename the time getters (d.hours -> d.hour, d.minutes -> d.minute, ...):
> http://dartbug.com/1985
> // florian
> --
> Give a man a fire and he's warm for the whole day,
> but set fire to him and he's warm for the rest of his life. - Terry
> Pratchett
The idea is to make it easier to use for the general case, and *not*
> implement a feature complete Date library. We eventually need something
> like Java's Joda library, but such a library would be way too big for the
> corelib and would confuse most people (Dates, DateTimes, and TimeZones are
> unfortunately pretty complicated...).
if I understand correctly, your argument and your code is based on the
assumption that timezones are hard, make the code complicated and in a vast
majority of situations, they aren't even necessary. I completely and
wholeheartedly agree. Having the corelib's date/time support as much
timezones-free as possible is a goal I can identify with.
From looking at the proposed Date interface, it looks like it can't be
completely timezones-free (because even the unix timestamp value refers to
UTC), so instead, the date is implicitly in local timezone. Correct? I
guess I can live with that.
> I also propose closing http://dartbug.com/1424 (Split into Date and
> TimeStamp). This is outside the scope of the corelib.
I still believe that having separate Date and DateTime in the corelib (both
of them in local timezone) is extremely valuable, because using date+time
value for modeling date value gets inconvenient pretty quickly. I'm
obviously not the one to decide what is in corelib's scope and what isn't,
but I'd plead for considering this once more.
On Mon, May 14, 2012 at 4:31 PM, Ladislav Thon <ladi...@gmail.com> wrote:
> Hi,
> The idea is to make it easier to use for the general case, and *not*
>> implement a feature complete Date library. We eventually need something
>> like Java's Joda library, but such a library would be way too big for the
>> corelib and would confuse most people (Dates, DateTimes, and TimeZones are
>> unfortunately pretty complicated...).
> if I understand correctly, your argument and your code is based on the
> assumption that timezones are hard, make the code complicated and in a vast
> majority of situations, they aren't even necessary. I completely and
> wholeheartedly agree. Having the corelib's date/time support as much
> timezones-free as possible is a goal I can identify with.
Correct: no (explicit) timezones in the corelib.
> From looking at the proposed Date interface, it looks like it can't be
> completely timezones-free (because even the unix timestamp value refers to
> UTC), so instead, the date is implicitly in local timezone. Correct? I
> guess I can live with that.
Yes. Dates will always be (implicitly) in the local timezone.
>> I also propose closing http://dartbug.com/1424 (Split into Date and
>> TimeStamp). This is outside the scope of the corelib.
> I still believe that having separate Date and DateTime in the corelib
> (both of them in local timezone) is extremely valuable, because using
> date+time value for modeling date value gets inconvenient pretty quickly.
> I'm obviously not the one to decide what is in corelib's scope and what
> isn't, but I'd plead for considering this once more.
From my point of view the biggest problem is that there is a lot of
pressure to make "Date" the DateTime class leaving no good name for the
actual Date class. I will think about this, but I think I would rather make
working with Dates easier by providing something like an "Interval" class
(similar to the Duration class) that deals nicer with Dates. For example:
date + new Interval(months: 3, days: 1)
> LT
-- Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett
On Mon, May 14, 2012 at 4:31 PM, Paul Brauner <po...@google.com> wrote:
> Something I often need is the equivalent of Date.fromEpoch but with
> human-readable arguments. Otherwise I keep going to
> http://www.epochconverter.com/ and I put the human-readable UTC date in a
> comment next to the timestamp. It doesn't add any expressivity, just
> readability.
I would use Date.fromString("ISO8601") for this. It would of course be
slower, but that would be the case for anything that doesn't provide the
epoch value.
> On Mon, May 14, 2012 at 3:59 PM, Florian Loitsch <floit...@google.com>wrote:
>> I'm in the process of refactoring the corelib's Date class, and would
>> like to get some feedback on this.
>> The idea is to make it easier to use for the general case, and *not*
>> implement a feature complete Date library. We eventually need something
>> like Java's Joda library, but such a library would be way too big for the
>> corelib and would confuse most people (Dates, DateTimes, and TimeZones are
>> unfortunately pretty complicated...).
>> As a first step I want to do the modifications I propose in CL
>> https://chromiumcodereview.appspot.com/10384149 >> That is: remove the TimeZone class, make Date hashable, add optional
>> arguments to the constructor and add a way to get to the TimeZone(offset).
>> The biggest change in the CL is that it would not be possible to get to
>> the UTC fields anymore. There would be a toUTCString() but no utcMonth (or
>> any other getter).
>> The reasoning is that timezone-independent operations almost always only
>> want the epoch-time (which is accessible through the 'value' field), or
>> print it (for logging). Both use-cases are still covered.
>> The following bugs would be obsolete if I go ahead with my changes:
>> TimeZone utc/local constructors should be constants:
>> http://dartbug.com/2581 >> DateImplementation doesn't check for required timezone argument:
>> http://dartbug.com/1260
>> I also propose closing http://dartbug.com/1424 (Split into Date and
>> TimeStamp). This is outside the scope of the corelib.
>> And since I start the discussion on Dates we should maybe also look at
>> adding support for some other epochs:
>> We should also consider:
>> Rename the time getters (d.hours -> d.hour, d.minutes -> d.minute, ...):
>> http://dartbug.com/1985
>> // florian
>> --
>> Give a man a fire and he's warm for the whole day,
>> but set fire to him and he's warm for the rest of his life. - Terry
>> Pratchett
-- Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett
On Mon, May 14, 2012 at 4:41 PM, Florian Loitsch <floit...@google.com> wrote:
> On Mon, May 14, 2012 at 4:31 PM, Ladislav Thon <ladi...@gmail.com> wrote:
>> Hi,
>>> The idea is to make it easier to use for the general case, and *not*
>>> implement a feature complete Date library. We eventually need something like
>>> Java's Joda library, but such a library would be way too big for the corelib
>>> and would confuse most people (Dates, DateTimes, and TimeZones are
>>> unfortunately pretty complicated...).
>> if I understand correctly, your argument and your code is based on the
>> assumption that timezones are hard, make the code complicated and in a vast
>> majority of situations, they aren't even necessary. I completely and
>> wholeheartedly agree. Having the corelib's date/time support as much
>> timezones-free as possible is a goal I can identify with.
> Correct: no (explicit) timezones in the corelib.
How should that look like? In the past years I needed access to
perfect timezone support (I am a Joda fan) and really cannot imagine
how it would work without.
>> From looking at the proposed Date interface, it looks like it can't be
>> completely timezones-free (because even the unix timestamp value refers to
>> UTC), so instead, the date is implicitly in local timezone. Correct? I guess
>> I can live with that.
> Yes. Dates will always be (implicitly) in the local timezone.
Horrible outlook if I can't change the timezone.
Maybe I miss something, but if not, please reconsider. I constantly
need timezone calculations and would like to avoid writing my own lib.
>>> I also propose closing http://dartbug.com/1424 (Split into Date and
>>> TimeStamp). This is outside the scope of the corelib.
>> I still believe that having separate Date and DateTime in the corelib
>> (both of them in local timezone) is extremely valuable, because using
>> date+time value for modeling date value gets inconvenient pretty quickly.
>> I'm obviously not the one to decide what is in corelib's scope and what
>> isn't, but I'd plead for considering this once more.
> From my point of view the biggest problem is that there is a lot of pressure
> to make "Date" the DateTime class leaving no good name for the actual Date
> class. I will think about this, but I think I would rather make working with
> Dates easier by providing something like an "Interval" class (similar to the
> Duration class) that deals nicer with Dates. For example: date + new
> Interval(months: 3, days: 1)
>> LT
> --
> Give a man a fire and he's warm for the whole day,
> but set fire to him and he's warm for the rest of his life. - Terry
> Pratchett
> On Mon, May 14, 2012 at 4:41 PM, Florian Loitsch <floit...@google.com>
> wrote:
> > On Mon, May 14, 2012 at 4:31 PM, Ladislav Thon <ladi...@gmail.com>
> wrote:
> >> Hi,
> >>> The idea is to make it easier to use for the general case, and *not*
> >>> implement a feature complete Date library. We eventually need
> something like
> >>> Java's Joda library, but such a library would be way too big for the
> corelib
> >>> and would confuse most people (Dates, DateTimes, and TimeZones are
> >>> unfortunately pretty complicated...).
> >> if I understand correctly, your argument and your code is based on the
> >> assumption that timezones are hard, make the code complicated and in a
> vast
> >> majority of situations, they aren't even necessary. I completely and
> >> wholeheartedly agree. Having the corelib's date/time support as much
> >> timezones-free as possible is a goal I can identify with.
> > Correct: no (explicit) timezones in the corelib.
> How should that look like? In the past years I needed access to
> perfect timezone support (I am a Joda fan) and really cannot imagine
> how it would work without.
Similar to Java this functionality would be provided by a separate library.
If you need the complexity then you have to ask for it.
One reason for this (as already mentioned) is not to confuse developers
that just want to do simple Date operations. The other is, that a Joda like
library requires a lot of space; both in terms of code-size as well as in
data.
> >> From looking at the proposed Date interface, it looks like it can't be
> >> completely timezones-free (because even the unix timestamp value refers
> to
> >> UTC), so instead, the date is implicitly in local timezone. Correct? I
> guess
> >> I can live with that.
> > Yes. Dates will always be (implicitly) in the local timezone.
> Horrible outlook if I can't change the timezone.
> Maybe I miss something, but if not, please reconsider. I constantly
> need timezone calculations and would like to avoid writing my own lib.
Somebody will have to write (or port) a lib, but with a little bit of luck
it will not be you ;)
> That being said time in millis is always useful.
> >>> I also propose closing http://dartbug.com/1424 (Split into Date and
> >>> TimeStamp). This is outside the scope of the corelib.
> >> I still believe that having separate Date and DateTime in the corelib
> >> (both of them in local timezone) is extremely valuable, because using
> >> date+time value for modeling date value gets inconvenient pretty
> quickly.
> >> I'm obviously not the one to decide what is in corelib's scope and what
> >> isn't, but I'd plead for considering this once more.
> > From my point of view the biggest problem is that there is a lot of
> pressure
> > to make "Date" the DateTime class leaving no good name for the actual
> Date
> > class. I will think about this, but I think I would rather make working
> with
> > Dates easier by providing something like an "Interval" class (similar to
> the
> > Duration class) that deals nicer with Dates. For example: date + new
> > Interval(months: 3, days: 1)
> >> LT
> > --
> > Give a man a fire and he's warm for the whole day,
> > but set fire to him and he's warm for the rest of his life. - Terry
> > Pratchett
> > Correct: no (explicit) timezones in the corelib.
> How should that look like? In the past years I needed access to
> perfect timezone support (I am a Joda fan) and really cannot imagine
> how it would work without.
Even JodaTime (and ThreeTen too, IIRC) has Local[Date|DateTime|Time], and
from my experience, timezone-less date values are far more common than the
other ones. So I guess that the plan is to have a separate library with all
those bells, timezones and whistles, but keep some small and most useful
fraction of it right in the corelib.
A Date represents an absolute time (what many people would call a UTC
time) - an actual epoch value, that refers to
an instant that is the same around the world. That will definitely not change.
Almost all of the functions for converting Dates to strings, and
getting hours, minutes, days, seconds from them, and for creating and
modifying dates will use the local time zone to convert to local time,
and will assume their inputs are in local time. This is also the same
as before
Date is not really a good way for representing calendar days. If you
make a Date from a calendar day, that Date is dependent on your local
timezone, and if its value as a Date object somehow gets to another
computer, it may not represent a time on that same day. It is also
hard to add and subtract days, with summer daylight time changes
happening. This makes the problem no better or worse. The real
solution is a different object for calendar days, or a UTC calendar
day that is easy to use.
What the previous API had was storing the time zone (from creation)
along with the Date, and using that, rather than the current active
time zone, for input/output/conversion (I think). Usually there would
be no difference between the two.
I would like to know if this makes it any harder to do input/output from UTC.
On Mon, May 14, 2012 at 4:46 PM, Christian Grobmeier
<grobme...@gmail.com> wrote:
> On Mon, May 14, 2012 at 4:41 PM, Florian Loitsch <floit...@google.com> wrote:
>> On Mon, May 14, 2012 at 4:31 PM, Ladislav Thon <ladi...@gmail.com> wrote:
>>> Hi,
>>>> The idea is to make it easier to use for the general case, and *not*
>>>> implement a feature complete Date library. We eventually need something like
>>>> Java's Joda library, but such a library would be way too big for the corelib
>>>> and would confuse most people (Dates, DateTimes, and TimeZones are
>>>> unfortunately pretty complicated...).
>>> if I understand correctly, your argument and your code is based on the
>>> assumption that timezones are hard, make the code complicated and in a vast
>>> majority of situations, they aren't even necessary. I completely and
>>> wholeheartedly agree. Having the corelib's date/time support as much
>>> timezones-free as possible is a goal I can identify with.
>> Correct: no (explicit) timezones in the corelib.
> How should that look like? In the past years I needed access to
> perfect timezone support (I am a Joda fan) and really cannot imagine
> how it would work without.
>>> From looking at the proposed Date interface, it looks like it can't be
>>> completely timezones-free (because even the unix timestamp value refers to
>>> UTC), so instead, the date is implicitly in local timezone. Correct? I guess
>>> I can live with that.
>> Yes. Dates will always be (implicitly) in the local timezone.
> Horrible outlook if I can't change the timezone.
> Maybe I miss something, but if not, please reconsider. I constantly
> need timezone calculations and would like to avoid writing my own lib.
> That being said time in millis is always useful.
>>>> I also propose closing http://dartbug.com/1424 (Split into Date and
>>>> TimeStamp). This is outside the scope of the corelib.
>>> I still believe that having separate Date and DateTime in the corelib
>>> (both of them in local timezone) is extremely valuable, because using
>>> date+time value for modeling date value gets inconvenient pretty quickly.
>>> I'm obviously not the one to decide what is in corelib's scope and what
>>> isn't, but I'd plead for considering this once more.
>> From my point of view the biggest problem is that there is a lot of pressure
>> to make "Date" the DateTime class leaving no good name for the actual Date
>> class. I will think about this, but I think I would rather make working with
>> Dates easier by providing something like an "Interval" class (similar to the
>> Duration class) that deals nicer with Dates. For example: date + new
>> Interval(months: 3, days: 1)
>>> LT
>> --
>> Give a man a fire and he's warm for the whole day,
>> but set fire to him and he's warm for the rest of his life. - Terry
>> Pratchett
-- William Hesse
Software Engineer
whe...@google.com
Google Denmark ApS
Frederiksborggade 20B, 1 sal
1360 København K
Denmark
CVR nr. 28 86 69 84
If you received this communication by mistake, please don't forward it
to anyone else (it may contain confidential or privileged
information), please erase all copies of it, including all
attachments, and please let the sender know it went to the wrong
person. Thanks.
>> > Correct: no (explicit) timezones in the corelib.
>> How should that look like? In the past years I needed access to
>> perfect timezone support (I am a Joda fan) and really cannot imagine
>> how it would work without.
> Similar to Java this functionality would be provided by a separate library.
> If you need the complexity then you have to ask for it.
> One reason for this (as already mentioned) is not to confuse developers that
> just want to do simple Date operations. The other is, that a Joda like
> library requires a lot of space; both in terms of code-size as well as in
> data.
I would find it pretty confusing if I can't fix my code because I have
no timezone avail :-)
I have learned there is no "simple date operation", even when it looks simple.
>> >> From looking at the proposed Date interface, it looks like it can't be
>> >> completely timezones-free (because even the unix timestamp value refers
>> >> to
>> >> UTC), so instead, the date is implicitly in local timezone. Correct? I
>> >> guess
>> >> I can live with that.
>> > Yes. Dates will always be (implicitly) in the local timezone.
>> Horrible outlook if I can't change the timezone.
>> Maybe I miss something, but if not, please reconsider. I constantly
>> need timezone calculations and would like to avoid writing my own lib.
> Somebody will have to write (or port) a lib, but with a little bit of luck
> it will not be you ;)
With my luck, I will write it :-)
In any case, if you can create a (readable) field naming the time zone
in which the date was created would probably help debugging.
And a chance to return the time in millis would be fine
>> That being said time in millis is always useful.
>> >>> I also propose closing http://dartbug.com/1424 (Split into Date and
>> >>> TimeStamp). This is outside the scope of the corelib.
>> >> I still believe that having separate Date and DateTime in the corelib
>> >> (both of them in local timezone) is extremely valuable, because using
>> >> date+time value for modeling date value gets inconvenient pretty
>> >> quickly.
>> >> I'm obviously not the one to decide what is in corelib's scope and what
>> >> isn't, but I'd plead for considering this once more.
>> > From my point of view the biggest problem is that there is a lot of
>> > pressure
>> > to make "Date" the DateTime class leaving no good name for the actual
>> > Date
>> > class. I will think about this, but I think I would rather make working
>> > with
>> > Dates easier by providing something like an "Interval" class (similar to
>> > the
>> > Duration class) that deals nicer with Dates. For example: date + new
>> > Interval(months: 3, days: 1)
>> >> LT
>> > --
>> > Give a man a fire and he's warm for the whole day,
>> > but set fire to him and he's warm for the rest of his life. - Terry
>> > Pratchett
On Mon, May 14, 2012 at 4:56 PM, Ladislav Thon <ladi...@gmail.com> wrote:
>> > Correct: no (explicit) timezones in the corelib.
>> How should that look like? In the past years I needed access to
>> perfect timezone support (I am a Joda fan) and really cannot imagine
>> how it would work without.
> Even JodaTime (and ThreeTen too, IIRC) has Local[Date|DateTime|Time], and
> from my experience, timezone-less date values are far more common than the
> other ones. So I guess that the plan is to have a separate library with all
> those bells, timezones and whistles, but keep some small and most useful
> fraction of it right in the corelib.
Like java.util.Date, the Calendar classes and Joda, which now becomes
part of the SDK?
Hope it will not cause more confusion than expected.
> Like java.util.Date, the Calendar classes and Joda, which now becomes
> part of the SDK?
> Hope it will not cause more confusion than expected.
I'm pretty sure that nowadays, noone would publish a date library similar
to java.util.Date or Calendar :-) And ThreeTen is quite different from
Joda. I'd love to have Stephen Colebourne (co)designing Dart's date
library, but I'm also sure that there already are some skilled people in
the Dart team.
A lot of applications (I'd argue that *majority* of applications) only
makes sense in a single timezone and their developers (myself included)
don't really understand this stuff. Let's not complicate their lifes.
On Mon, May 14, 2012 at 5:10 PM, Ladislav Thon <ladi...@gmail.com> wrote:
>> Like java.util.Date, the Calendar classes and Joda, which now becomes
>> part of the SDK?
>> Hope it will not cause more confusion than expected.
> I'm pretty sure that nowadays, noone would publish a date library similar to
> java.util.Date or Calendar :-) And ThreeTen is quite different from Joda.
I am referring to the fact that java.util.Date has not timezone
support and gives you month/day/year etc. It is pretty simple and
sound pretty much like what is proposed: a simple Date class with a
single timezone.
> I'd love to have Stephen Colebourne (co)designing Dart's date library, but
> I'm also sure that there already are some skilled people in the Dart team.
It did not doubt that.
> A lot of applications (I'd argue that majority of applications) only makes
> sense in a single timezone and their developers (myself included) don't
> really understand this stuff. Let's not complicate their lifes.
I am not sure why these signatures are considered complicated or confusing:
new Date(); // fixed timezone or underlying os timezone
new Date.germany();
new Date.utc(5); // utc +5
I highly doubt that people who deal with Date don't need access to TimeZone.
Either I have had bad luck but the past years I constantly worked on
applications which needed timezones. I am also not talking about
creating a killer-lib like JodaTime but completely getting rid of
timezones sounds wrong to me.
But well, at least I hope the new Date-classes allow creating a proper
lib. Anyway without such a lib I cannot move to Dart, stable or not.
> I'm in the process of refactoring the corelib's Date class, and would like
> to get some feedback on this.
> The idea is to make it easier to use for the general case, and *not*
> implement a feature complete Date library. We eventually need something
> like Java's Joda library, but such a library would be way too big for the
> corelib and would confuse most people (Dates, DateTimes, and TimeZones are
> unfortunately pretty complicated...).
> As a first step I want to do the modifications I propose in CL
> https://chromiumcodereview.appspot.com/10384149 > That is: remove the TimeZone class, make Date hashable, add optional
> arguments to the constructor and add a way to get to the TimeZone(offset).
> The biggest change in the CL is that it would not be possible to get to
> the UTC fields anymore. There would be a toUTCString() but no utcMonth (or
> any other getter).
> The reasoning is that timezone-independent operations almost always only
> want the epoch-time (which is accessible through the 'value' field), or
> print it (for logging). Both use-cases are still covered.
> The following bugs would be obsolete if I go ahead with my changes:
> TimeZone utc/local constructors should be constants:
> http://dartbug.com/2581 > DateImplementation doesn't check for required timezone argument:
> http://dartbug.com/1260
> I also propose closing http://dartbug.com/1424 (Split into Date and
> TimeStamp). This is outside the scope of the corelib.
> And since I start the discussion on Dates we should maybe also look at
> adding support for some other epochs:
> We should also consider:
> Rename the time getters (d.hours -> d.hour, d.minutes -> d.minute, ...):
> http://dartbug.com/1985
> // florian
> --
> Give a man a fire and he's warm for the whole day,
> but set fire to him and he's warm for the rest of his life. - Terry
> Pratchett
-- Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett
On Mon, May 14, 2012 at 9:41 AM, Florian Loitsch <floit...@google.com> wrote:
> From my point of view the biggest problem is that there is a lot of pressure
> to make "Date" the DateTime class leaving no good name for the actual Date
> class.
I would rename Date to Time, that is what Ruby and Go have:
For the other interface, I would consider using Day instead of Date to
avoid any confusion with Date in Java/JavaScript.
'time of day' abstractions are not that common, but if needed, it
could be named TimeOfDay.
> I will think about this, but I think I would rather make working with
> Dates easier by providing something like an "Interval" class (similar to the
> Duration class) that deals nicer with Dates. For example: date + new
> Interval(months: 3, days: 1)
I think the term 'Interval' implies a contiguous interval between two
absolute values which are Comparable such as Date/Time, e.g.:
interface Interval<T extends Comparable> {
Interval(T one, T other);
final T start, end;
bool contains(T test);
}
As far as modeling day, week, month, and year deltas independent of
daylight savings time, varying month lengths, and leap years, I think
this should be added directly to Duration, or at least a sub-interface
thereof. This is tracked in http://dartbug.com/1426.
This can be done by having exact, non-additive fields for
milliseconds, days, and months, and then estimated additive getters
for all units, i.e. inMilliseconds ... inYears.
The Duration returned from Date/Time#difference would have a slightly
different implementation since it can provide exact values for the all
units, yet it would still only need to store a subset of milliseconds,
days, and months values internally.
On May 14, 6:10 pm, Ladislav Thon <ladi...@gmail.com> wrote:
> > Like java.util.Date, the Calendar classes and Joda, which now becomes
> > part of the SDK?
> > Hope it will not cause more confusion than expected.
> I'm pretty sure that nowadays, noone would publish a date library similar
> to java.util.Date or Calendar :-) And ThreeTen is quite different from
> Joda. I'd love to have Stephen Colebourne (co)designing Dart's date
> library, but I'm also sure that there already are some skilled people in
> the Dart team.
> A lot of applications (I'd argue that *majority* of applications) only
> makes sense in a single timezone and their developers (myself included)
> don't really understand this stuff. Let's not complicate their lifes.
On Mon, May 14, 2012 at 8:59 AM, Florian Loitsch <floit...@google.com> wrote:
> The idea is to make it easier to use for the general case, and *not*
> implement a feature complete Date library. We eventually need something like
> Java's Joda library, but such a library would be way too big for the corelib
> and would confuse most people (Dates, DateTimes, and TimeZones are
> unfortunately pretty complicated...).
I agree with keeping the size of dart:core down. I don't agree that
providing micro date/time APIs in dart:core is the solution. I think
these APIs would be abandoned, forever cluttering the top level
namespace of libraries, after a more full featured library came along.
I think a better option would be to provide a placeholder for that
more full featured library now, probably called "dart:time", which
contains Date, Duration, and TimeZone. Having the local time zone as
the default already means you don't have to think about time zones if
you don't want to. And if a better name were used instead of Date
(outside of computer science this refers to an entire day, not an
instant), such as Time, Instant, or Moment, then a class to represent
an entire day, called Date or Day, could be added to this library
either now or in the future. Other things could be added in the
future as well as pain points are discovered.
On Tue, May 15, 2012 at 10:25 AM, Sean Eagan <seaneag...@gmail.com> wrote:
> On Mon, May 14, 2012 at 8:59 AM, Florian Loitsch <floit...@google.com> wrote:
>> The idea is to make it easier to use for the general case, and *not*
>> implement a feature complete Date library. We eventually need something like
>> Java's Joda library, but such a library would be way too big for the corelib
>> and would confuse most people (Dates, DateTimes, and TimeZones are
>> unfortunately pretty complicated...).
> I agree with keeping the size of dart:core down. I don't agree that
> providing micro date/time APIs in dart:core is the solution. I think
> these APIs would be abandoned, forever cluttering the top level
> namespace of libraries, after a more full featured library came along.
> I think a better option would be to provide a placeholder for that
> more full featured library now, probably called "dart:time", which
> contains Date, Duration, and TimeZone. Having the local time zone as
> the default already means you don't have to think about time zones if
> you don't want to. And if a better name were used instead of Date
> (outside of computer science this refers to an entire day, not an
> instant), such as Time, Instant, or Moment, then a class to represent
> an entire day, called Date or Day, could be added to this library
> either now or in the future. Other things could be added in the
> future as well as pain points are discovered.
On Tue, May 15, 2012 at 2:00 PM, afsina <ahme...@gmail.com> wrote:
> On May 14, 6:10 pm, Ladislav Thon <ladi...@gmail.com> wrote:
> > > Like java.util.Date, the Calendar classes and Joda, which now becomes
> > > part of the SDK?
> > > Hope it will not cause more confusion than expected.
> > I'm pretty sure that nowadays, noone would publish a date library similar
> > to java.util.Date or Calendar :-) And ThreeTen is quite different from
> > Joda. I'd love to have Stephen Colebourne (co)designing Dart's date
> > library, but I'm also sure that there already are some skilled people in
> > the Dart team.
> > A lot of applications (I'd argue that *majority* of applications) only
> > makes sense in a single timezone and their developers (myself included)
> > don't really understand this stuff. Let's not complicate their lifes.
Afaics there are no results yet. They should be available soon, though.
When they are, don't hesitate to send an update to the list.
thanks,
// florian
> Ahmet
-- Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett
On Tue, May 15, 2012 at 5:25 PM, Sean Eagan <seaneag...@gmail.com> wrote:
> On Mon, May 14, 2012 at 8:59 AM, Florian Loitsch <floit...@google.com>
> wrote:
> > The idea is to make it easier to use for the general case, and *not*
> > implement a feature complete Date library. We eventually need something
> like
> > Java's Joda library, but such a library would be way too big for the
> corelib
> > and would confuse most people (Dates, DateTimes, and TimeZones are
> > unfortunately pretty complicated...).
> I agree with keeping the size of dart:core down. I don't agree that
> providing micro date/time APIs in dart:core is the solution. I think
> these APIs would be abandoned, forever cluttering the top level
> namespace of libraries, after a more full featured library came along.
> I think a better option would be to provide a placeholder for that
> more full featured library now, probably called "dart:time", which
> contains Date, Duration, and TimeZone. Having the local time zone as
> the default already means you don't have to think about time zones if
> you don't want to. And if a better name were used instead of Date
> (outside of computer science this refers to an entire day, not an
> instant), such as Time, Instant, or Moment, then a class to represent
> an entire day, called Date or Day, could be added to this library
> either now or in the future. Other things could be added in the
> future as well as pain points are discovered.
> Thoughts?
We are discussing moving even the simplified version of Date into its own
library (for instance "dart:date"). So far no conclusion has been reached.
Wrt the naming. Yes, keeping the names consistent would be a plus, but
"Date" seems to be pretty entrenched. Also, because there is just no really
good substitute. None of DateTime, Time, Instant or Moment is something
that is easily found.
// florian
> Cheers,
> Sean
-- Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett
On Wed, May 16, 2012 at 11:41 AM, Florian Loitsch <floit...@google.com>wrote:
> We are discussing moving even the simplified version of Date into its own
> library (for instance "dart:date").
+1
> Wrt the naming. Yes, keeping the names consistent would be a plus, but
> "Date" seems to be pretty entrenched. Also, because there is just no really
> good substitute. None of DateTime, Time, Instant or Moment is something
> that is easily found.
I think 'Date' is entrenched, but everyone has different expectations of it:
- New developers expect it to be a calendar date with no time attached
(as in English)
- People familiar with other languages expect it to have a timezone,
defaulting to local
- And Dart is (sensibly) considering making it a UTC timestamp
I think 'Instant' is a better name, because:
- Its plain-English meaning is closer to a timestamp than 'Date'
- It's not misleadingly similar different concepts from other languages
- most won't know it at all
- people familiar with Joda will get the correct idea
- people won't complain about it being different, most Date APIs suck
- There will be less pressure to include formatting methods (and thus
timezone logic) in this class if it's called Instant vs Date.
> We are discussing moving even the simplified version of Date into its own
>> library (for instance "dart:date").
> +1
>> Wrt the naming. Yes, keeping the names consistent would be a plus, but
>> "Date" seems to be pretty entrenched. Also, because there is just no really
>> good substitute. None of DateTime, Time, Instant or Moment is something
>> that is easily found.
> I think 'Date' is entrenched, but everyone has different expectations of
> it:
> - New developers expect it to be a calendar date with no time attached
> (as in English)
> - People familiar with other languages expect it to have a timezone,
> defaulting to local
> - And Dart is (sensibly) considering making it a UTC timestamp
> I think 'Instant' is a better name, because:
> - Its plain-English meaning is closer to a timestamp than 'Date'
> - It's not misleadingly similar different concepts from other languages
> - most won't know it at all
> - people familiar with Joda will get the correct idea
> - people won't complain about it being different, most Date APIs
> suck
> - There will be less pressure to include formatting methods (and thus
> timezone logic) in this class if it's called Instant vs Date.
+∞ to what Sam said. Extracting date stuff to separate library works fine
for me -- and it's a great opportunity to route people in the right
direction where the full-featured timezone-aware date library will be.
On Wed, May 16, 2012 at 5:41 AM, Florian Loitsch <floit...@google.com> wrote:
> We are discussing moving even the simplified version of Date into its own
> library (for instance "dart:date"). So far no conclusion has been reached.
Glad to hear that it is being considered. I assume Duration,
Stopwatch, Timer, Clock (and TimeZone if it were kept) would also be
moved there ?
In this case I think "dart:time" would be a much better name since
durations, stopwatches, and timers don't have much to do with dates,
but _are_ related to the concept of time. Here are some existing
libraries which use "time" as the library name:
> Wrt the naming. Yes, keeping the names consistent would be a plus
It's not just about consistency within Dart, but consistency with
English as well :).
> "Date" seems to be pretty entrenched.
But the _trend_ is moving away from "Date". Joda and eventually
ThreeTen use "Instant" / "DateTime", moment.js (http://momentjs.com)
uses "Moment". Go and Ruby use "Time". Python uses "DateTime".
> Also, because there is just no really
> good substitute. None of DateTime, Time, Instant or Moment is something that
> is easily found.
These all seem like improvements over "Date". And if this is in a
small "dart:time" library, then it should be quite easily found, once
the library itself is found at http://api.dartlang.org.
On Wed, May 16, 2012 at 1:00 PM, Sam McCall <sammcc...@google.com> wrote:
> On Wed, May 16, 2012 at 11:41 AM, Florian Loitsch <floit...@google.com>wrote:
>> We are discussing moving even the simplified version of Date into its own
>> library (for instance "dart:date").
> +1
>> Wrt the naming. Yes, keeping the names consistent would be a plus, but
>> "Date" seems to be pretty entrenched. Also, because there is just no really
>> good substitute. None of DateTime, Time, Instant or Moment is something
>> that is easily found.
> I think 'Date' is entrenched, but everyone has different expectations of
> it:
> - New developers expect it to be a calendar date with no time attached
> (as in English)
> - People familiar with other languages expect it to have a timezone,
> defaulting to local
> - And Dart is (sensibly) considering making it a UTC timestamp
> I think 'Instant' is a better name, because:
The problem with "Instant" is that it clashes with threeten. There
"Instant" is just a wrapper around the epoch-value. The equivalent class
would be "ZonedDateTime" and that's a no go for the simplified class name.
> - Its plain-English meaning is closer to a timestamp than 'Date'
> - It's not misleadingly similar different concepts from other languages
> - most won't know it at all
> - people familiar with Joda will get the correct idea
> - people won't complain about it being different, most Date APIs
> suck
> - There will be less pressure to include formatting methods (and thus
> timezone logic) in this class if it's called Instant vs Date.
> Cheers,
> Sam
-- Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett
> On Wed, May 16, 2012 at 1:00 PM, Sam McCall <sammcc...@google.com> wrote:
>> On Wed, May 16, 2012 at 11:41 AM, Florian Loitsch <floit...@google.com>wrote:
>>> We are discussing moving even the simplified version of Date into its
>>> own library (for instance "dart:date").
>> +1
>>> Wrt the naming. Yes, keeping the names consistent would be a plus, but
>>> "Date" seems to be pretty entrenched. Also, because there is just no really
>>> good substitute. None of DateTime, Time, Instant or Moment is something
>>> that is easily found.
>> I think 'Date' is entrenched, but everyone has different expectations of
>> it:
>> - New developers expect it to be a calendar date with no time
>> attached (as in English)
>> - People familiar with other languages expect it to have a timezone,
>> defaulting to local
>> - And Dart is (sensibly) considering making it a UTC timestamp
>> I think 'Instant' is a better name, because:
> The problem with "Instant" is that it clashes with threeten. There
> "Instant" is just a wrapper around the epoch-value. The equivalent class
> would be "ZonedDateTime" and that's a no go for the simplified class name.
I'm confused, I thought we were talking about a 'wrapper around an
epoch-value' - that's the baseline that I'd expect to be (almost) part of
the language.
Once you start including timezones then the complexity comes in, and I
agree there's not a great name for that - but it would be one name among
several in such a library (c.f. joda/threeten) and so it would be easier to
draw distinctions through a naming system.
