UTCDateAndTime updated for Squeak 4.6/5.0
Locked
1234
1234
Re: Class comment for Date mentions #localizedDates
 
|
Hi Dave, all of the Timespans are instantiated as positions by default
(e.g., ignoring timezone), which is the common case. If/when someone might need a Date, Month, Week, etc. which begins at a timezone-specific time, they will be glad to see that it is handled automatically. For example, when adding a Timespan to a DateAndTime with the #+ message, the result gets the same offset as the receiver. But this uncommon case is revealed at method-level code and comments, so I would just simplify the class comment to: Instances of Date are Timespans with duration of 1 day. Oh, i like that. It reflects the simplicity and elegance of Chronology's implementation which is able to interoperate with itself. Best, Chris > Would the following work as a class comment for Date? > > Date provides methods for dealing with calendar dates in different formats. > > Instances of Date are Timespans with duration of 1 day beginning at midnight. > The start value of midnight, and possibly the duration of 1 day, depend on > the time zone in which the Date is defined. > > In the most common usage, a Date is defined relative to UTC (time zone offset > zero), and thus may be treated as a location independent calendar value. > > The current date, Date today, is assumed to be defined as a UTC date without > consideration of local time zone. > > > Dave > > > On Sun, Jun 26, 2016 at 11:30:35PM -0400, David T. Lewis wrote: >> Hi Chris, >> >> I was really just trying to ask for a good class comment. The current >> comment contains an error, and I used that as an excuse for raising the >> question. >> >> I want to know the *meaning* of the Date class. And I would like the >> class comment to say what it means. The meaning seems to have changed >> considerably over the last ten or fifteen years as the implementations >> have changed, and I think that it would be helpful if the current >> definition could be stated as clearly as possible. >> >> >> On Sat, Jun 25, 2016 at 07:34:02PM -0500, Chris Muller wrote: >> > Hi Dave, Dates created as positions by default is the definitely the >> > correct behavior. The original Date implementation inherited the >> > abstraction from Timespan of a custom duration starting at a >> > particular DateAndTime. While that is a fine for abstract Timespans, >> > it turned out to be a bad idea for Dates, since the vast majority of >> > the use of Dates are as positions, not spans. >> >> I am not sure what is meant by "Dates as positions". When I first read >> this, I was thinking of "position relative to GMT" but on reading it >> again I realized that it probably means "position on a continuum of date >> values". Or maybe I am just completely confused (hence my plea for a >> good class comment). Despite my confusion, my own best guess at the >> current intended meaning of "Date" was in my original question below. >> >> A bit off topic, but is is worth asking: >> If we really want to model Date as a position on a continuum of date >> values, and if we think that the implementation of Date as a kind of >> Timespan is not right, then shouldn't we just consider going back to >> the earlier (Squeak 3.6 and earlier) implementation of Date as a Magnitude, >> rather than Date as a Timespan? >> >> Dave >> >> > >> > Check out the discussion surrounding Berts recent clarification of the >> > implementation, where the timezone for Dates-as-positions is now set >> > to nil, so the "localized" or "globalized" nomenclature can be removed >> > from the comment. >> > >> > - Chris >> > >> > >> > On Thu, Jun 23, 2016 at 8:05 AM, David T. Lewis <[hidden email]> wrote: >> > > The class comment says: >> > > >> > > Instances of Date are Timespans with duration of 1 day. >> > > >> > > Their default creation assumes a start of midnight of UTC to provide the fast, globalized Dates out of the box. The legacy behavior that creates Timezone-sensitive Dates can be used by sending #localizedDates. >> > > >> > > >> > > I no longer see #localizedDates in the image, so I think the comment needs an update. >> > > >> > > >> > > For reference, and earlier version of the class comment said this: >> > > >> > > Instances of Date are Timespans with duration of 1 day. >> > > Their default creation assumes a start of midnight in the local time zone. >> > > >> > > >> > > I am not sure what the comment should say, but I would be happy if it could >> > > better convey the intended meaning of "Date" in addition to the explanation >> > > about creating instances relative to UTC versus local time zone. >> > > >> > > My expectation would be that a Date is a Timespan with a start value set to >> > > midnight in some time zone. The start value is a DateAndTime, and the offset >> > > instance variable of that DateAndTime would reflect that time zone. >> > > >> > > I would therefore expect that a "globalized" Date is a special case of a Date >> > > that was created with the start of the Timespan at midnight UTC, regardless >> > > of the current local time zone. A "globalized" Date is no different from any >> > > other Date, it is simply a Date that was created with time zone UTC. >> > > >> > > Is that right? >> > > >> > > Dave >> > > >> > > > |
Re: Class comment for Date mentions #localizedDates
|
|
In reply to this post by Louis LaBrunda
On Mon, Jun 27, 2016 at 5:47 AM, Louis LaBrunda <[hidden email]> wrote: Hi Dave, I hope we can settle on representing them as microseconds. Using nanoseconds (the Microsoft granularity) shrinks their usable time span to 36 years if using 61-bit SmallIntegers, which is too short even if we use the posix epoch, and horrible if we want to rebase things, e.g. at 2000 or 2001. Keeping microseconds, which is the VM representation gives us ~36,000 years within the 61-bit SmallInteger range (- 2^60 - 2^60 - 1) in 64-bit Spur. Using milliseconds throws away precision and introduces a divide. Multiplying, or worse still dividing, by 1000 n every instantiation seems like a bad idea to me.
_,,,^..^,,,_ best, Eliot |
Re: Class comment for Date mentions #localizedDates
|
|
In reply to this post by cbc
Hi Chris,
On Mon, Jun 27, 2016 at 8:31 AM, Chris Cunningham <[hidden email]> wrote:
That's what I wonder. Can't we simply store the start time (ideally UTC microseconds or local microseconds) internally and then compute the duration programmatically, depending on the timezone in effect?
So if we store the start time isn't the conversion to a magnitude simply an inst var access?
_,,,^..^,,,_ best, Eliot |
|
|
So if we store the start time isn't the conversion to a magnitude simply an inst var access? That's mostly what I do. But it depends on how the Date is created. For instance, unless you live in the UTC time zone, the following is true: Date today = DateAndTime now asDate "==>true" Date today start = DateAndTime now asDate start "==>false" Date today start asSeconds = DateAndTime now asDate start asSeconds "==>true" And, of course, it isn't a DAY that we are talking about - it is a DateAndTime (a specific point in time). It's just remembering which corner cases are true, and which aren't, at any given time. (as an aside, I find it interesting that Timespan current gives you a day. It is what Date today is based off of - so don't ever change that Timespan #current method!) -cbc |
Re: Class comment for Date mentions #localizedDates
|
|
In reply to this post by Bert Freudenberg
On Mon, Jun 27, 2016 at 12:41:28PM +0200, Bert Freudenberg wrote:
> On Mon, Jun 27, 2016 at 5:30 AM, David T. Lewis <[hidden email]> wrote: > > > A bit off topic, but is is worth asking: > > If we really want to model Date as a position on a continuum of date > > values, and if we think that the implementation of Date as a kind of > > Timespan is not right, then shouldn't we just consider going back to > > the earlier (Squeak 3.6 and earlier) implementation of Date as a Magnitude, > > rather than Date as a Timespan? > > > > I think this is a very relevant question. We may have to distinguish a Day > from a Date. This seems like a useful distinction to me. The concepts are different, and they deserve different representations. To me as a native American English speaker, I would say that "Day" implies duration, and "Date" implies magnitude. I would expect that the current implementation of date as duration might map most directly to a Smalltalk class named "Day". And the earlier Squeak implementation of date as a magnitude would map directly to a Smalltalk class named "Date". > IMHO a birthday is a perfect example. It's defined by a day+month+year. If > I was traveling I would celebrate the birthday in local time, so the > generic "birthday" needs to compare equal to all the local dates > independent of time zone. > > This is how Dates worked before we made them Timespans (because they had no > time, and hence no time zone). And this is also how they worked after I > added the "nil" offset hack (which ignores the timezone). But it's a hack, > not a good design. I'm not entirely sure what a good design would look like > that also does not break old code. > > - Bert - If we can assume that the current Squeak implementation of Date as a duration makes sense for a class named "Day" and that the prior implementation of Date as a magnitude makes sense for a class named "Date", then a possible way forward would be (in someone's local image, not yet in trunk): - Rename class Date as Day - Copy the Date tests to a new class for the Day tests. - Make sure that the tests for Day are working. - Load an old version of Date from the most recent Squeak version that had Date as a magnitude. - Make the unit tests work for Date. Dave |
Re: Class comment for Date mentions #localizedDates
|
|
In reply to this post by cbc
On Mon, Jun 27, 2016 at 08:31:28AM -0700, Chris Cunningham wrote:
> So, Time and Dates are hard. When Date was a magnitude, it was easy. Now > that it is a duration, it is occassionally wrong. Think about daylight > savings time - at least one a year the day length is 25 hours, and once it > is 23 hours (although in some places there are no Daylight Savings, so this > isn't true, and in others, there are 2 switches, so it happens twice). Our > current implementation doesn't take this into account - which is reasonable > because it is hard to take this into account without a lot of work. Quite right. The concept of "one day" is ambiguous unless we know the local time zone in which it if defined. DST transitions, and possibly also handling of leap seconds, make it impossible to know the duration of one day without also knowing the time zone in which that day is defined. > > If we want to keep Date as a timespan (with rough correctness), maybe we > could also add in Day (as a magnitude) to work like the old Date? If we have Day and Date, then IMHO the Day class should represent duration, and the Date class should represent magnitude. > > For what it is worth, I spend >80% of my time working with > dates/timestamps, trying to turn them into Magnitudes for manipulations. > The other 20%, I really enjoy them as timespans with locales since I deal > with times from around the world. But the two uses are not quite easy to > deal with - doable, just not quite intuitive. > > -cbc Based on your experience, do you think that it would make sense to have two classes for Day and Date, where one represents date as duration, and the other represents date as magnitude? Dave > > On Mon, Jun 27, 2016 at 3:41 AM, Bert Freudenberg <[hidden email]> > wrote: > > > On Mon, Jun 27, 2016 at 5:30 AM, David T. Lewis <[hidden email]> > > wrote: > > > >> A bit off topic, but is is worth asking: > >> If we really want to model Date as a position on a continuum of date > >> values, and if we think that the implementation of Date as a kind of > >> Timespan is not right, then shouldn't we just consider going back to > >> the earlier (Squeak 3.6 and earlier) implementation of Date as a > >> Magnitude, > >> rather than Date as a Timespan? > >> > > > > I think this is a very relevant question. We may have to distinguish a Day > > from a Date. > > > > IMHO a birthday is a perfect example. It's defined by a day+month+year. If > > I was traveling I would celebrate the birthday in local time, so the > > generic "birthday" needs to compare equal to all the local dates > > independent of time zone. > > > > This is how Dates worked before we made them Timespans (because they had > > no time, and hence no time zone). And this is also how they worked after I > > added the "nil" offset hack (which ignores the timezone). But it's a hack, > > not a good design. I'm not entirely sure what a good design would look like > > that also does not break old code. > > > > - Bert - > > > > > > > > > > > |
Re: Class comment for Date mentions #localizedDates
|
|
In reply to this post by David T. Lewis
> If we can assume that the current Squeak implementation of Date as
> a duration makes sense for a class named "Day" and that the prior > implementation of Date as a magnitude makes sense for a class named > "Date", then a possible way forward would be (in someone's local image, > not yet in trunk): > > - Rename class Date as Day > - Copy the Date tests to a new class for the Day tests. > - Make sure that the tests for Day are working. > - Load an old version of Date from the most recent Squeak version that had Date as a magnitude. > - Make the unit tests work for Date. Hi Dave, I appreciate your point about the semantics of the word "Date" vs. "Day" but since DateAndTime is also part of Chronology, I hope you don't intend to rename it to "DayAndTime" and make it work with Days.. :) DateAndTime has #asHour, #asDate, #asMonth, #asYear -- each one returning an instance of the appropriate Timespan subclass. This proposal would interject a totally orthogonal "exception" into the API of Chronology. Your Magnitude version of Date would have a different API like #isTimespan, for example. So, it would break many applications not just from the format change, but their application logic too. That's too big a cost. I worked a lot with Brent for several years, I know his style is to make terse and elegant API's. Chronology provides us with a robust interoperation of inputs with its outputs. I happen to know the compactness of the API was a deliberate part of his legacy creation. We should respect that. > I was really just trying to ask for a good class comment. I really do think this is the best way to do this clarification. Did you notice that Bert already updated the class comment of Timespan to mention the dual capability? So, I think simply removing that old stuff from Date's comment is simple and effective solution without breaking legacy apps. |
Re: Class comment for Date mentions #localizedDates
|
|
On Tue, Jun 28, 2016 at 01:41:28PM -0500, Chris Muller wrote:
> > > I was really just trying to ask for a good class comment. > > I really do think this is the best way to do this clarification. Did > you notice that Bert already updated the class comment of Timespan to > mention the dual capability? So, I think simply removing that old > stuff from Date's comment is simple and effective solution without > breaking legacy apps. This was my attempt at a class comment for Date: Date provides methods for dealing with calendar dates in different formats. Instances of Date are Timespans with duration of 1 day beginning at midnight. The start value of midnight, and possibly the duration of 1 day, depend on the time zone in which the Date is defined. In the most common usage, a Date is defined relative to UTC (time zone offset zero), and thus may be treated as a location independent calendar value. The current date, Date today, is assumed to be defined as a UTC date without consideration of local time zone. Alternative attempts welcome :-) Dave |
Re: Class comment for Date mentions #localizedDates
|
|
On Tue, Jun 28, 2016 at 08:18:53PM -0400, David T. Lewis wrote:
> On Tue, Jun 28, 2016 at 01:41:28PM -0500, Chris Muller wrote: > > > > > I was really just trying to ask for a good class comment. > > > > I really do think this is the best way to do this clarification. Did > > you notice that Bert already updated the class comment of Timespan to > > mention the dual capability? So, I think simply removing that old > > stuff from Date's comment is simple and effective solution without > > breaking legacy apps. > > This was my attempt at a class comment for Date: > > Date provides methods for dealing with calendar dates in different formats. > > Instances of Date are Timespans with duration of 1 day beginning at midnight. > The start value of midnight, and possibly the duration of 1 day, depend on > the time zone in which the Date is defined. > > In the most common usage, a Date is defined relative to UTC (time zone offset > zero), and thus may be treated as a location independent calendar value. > > The current date, Date today, is assumed to be defined as a UTC date without > consideration of local time zone. > > Alternative attempts welcome :-) > > Dave > Chris, thanks for updating the class comment for Date. Summarizing where we are now: Brent's original class comment is: Instances of Date are Timespans with duration of 1 day. Their default creation assumes a start of midnight in the local time zone. And our class comment (Chronology-Core-cmm.6.mcz) is: Instances of Date are Timespans with duration of 1 day. As with all Chronology Timespan sub-instances, Dates can be instantiated as position values which compare equally to any other instance of the same Date, irregardless of the timezone in which either is created. However, like the other Timespan subInstances, there are rare cases where it may be desirable to use instances of Date to represent a particular 1-day span of time at a particular locality on the globe. All Timespans, including Dates, may specify a particular timezone offset for this purpose. It seems that Brent's intent was to represent a date starting at midnight in the local time zone. For various reasons, we now treat it more like a magnitude, representing it as a one day duration beginning at midnight UTC. That works better for most actual usage of class Date, but it does leave me thinking that we are mashing up two different concepts. To be clear, I am not planning to actually /do/ anything about this, I am just trying to clarify the documentation and my own understanding. It might well be a good idea to have two different classes to represent date as duration versus date as magnitude, but I certainly have no intention of taking that on until we decide to use or discard the UTCDateAndTime updates that I previously proposed. My primary motiviation is to make sure that the changes in UTCDateAndTime pass the unit tests while also respecting the design intent. So I am not trying to be a pain in the ass, I am really trying to understand the intended meaning of the class, and I am trying to reconcile Brent's original intent with the various changes that we have made since its introduction. Thanks :-) Dave |
|
|
In reply to this post by David T. Lewis
Hi David
On Mon, Jun 27, 2016 at 9:40 PM, David T. Lewis <[hidden email]> wrote: <snip> Sorry for the long delay. Having Date (or Day) as a duration has positive benefits. For instance, I want to know if a particular timestamp (when something happened, what we call DateAndTime) happened on a particular Date. The DateAndTime might be in a different timezone than the Date we are checking. Being able to just ask 'is this timestamp from this date' is nice: theDate := ('2016-07-06' asDate start offset: 4 hours) asDate. theTime := '2016-07-06 20:34:02' asDateAndTime offset: 8 hours. theDate includes: theTime " => false" theTime := '2016-07-06 20:34:02' asDateAndTime offset: -8 hours. theDate includes: theTime " => true" Although it is hard to get a date in a certain timezone - is there a better way than what I wrote above? Rarely do I need it in my timezone - instead I need to specify it directly or not have it present at all. Most of the time, though, I just as a number, not a duration. I just want to show it, sometimes work from its beginning to some other time, and ignore that it is a duration. Looking at how you are interpreting my statement that I want it as a magnitude, I think I was using the wrong words. What I really meant was that I wanted it ignore the duration (and most especially the timezone) - but not use it as a raw number of some kind. Thanks, -cbc |
Re: Class comment for Date mentions #localizedDates
|
|
> Hi David
> > On Mon, Jun 27, 2016 at 9:40 PM, David T. Lewis <[hidden email]> > wrote: > >> <snip> >> >> > >> > For what it is worth, I spend >80% of my time working with >> > dates/timestamps, trying to turn them into Magnitudes for >> manipulations. >> > The other 20%, I really enjoy them as timespans with locales since I >> deal >> > with times from around the world. But the two uses are not quite easy >> to >> > deal with - doable, just not quite intuitive. >> > >> > -cbc >> >> Based on your experience, do you think that it would make sense to have >> two classes for Day and Date, where one represents date as duration, and >> the other represents date as magnitude? >> >> Dave >> > > Sorry for the long delay. > > Having Date (or Day) as a duration has positive benefits. For instance, I > want to know if a particular timestamp (when something happened, what we > call DateAndTime) happened on a particular Date. The DateAndTime might be > in a different timezone than the Date we are checking. Being able to just > ask 'is this timestamp from this date' is nice: > > theDate := ('2016-07-06' asDate start offset: 4 hours) asDate. > theTime := '2016-07-06 20:34:02' asDateAndTime offset: 8 hours. > theDate includes: theTime " => false" > theTime := '2016-07-06 20:34:02' asDateAndTime offset: -8 hours. > theDate includes: theTime " => true" > > Although it is hard to get a date in a certain timezone - is there a > better > way than what I wrote above? Rarely do I need it in my timezone - instead > I need to specify it directly or not have it present at all. > > Most of the time, though, I just as a number, not a duration. I just want > to show it, sometimes work from its beginning to some other time, and > ignore that it is a duration. > > Looking at how you are interpreting my statement that I want it as a > magnitude, I think I was using the wrong words. What I really meant was > that I wanted it ignore the duration (and most especially the timezone) - > but not use it as a raw number of some kind. > > Thanks, > -cbc > > Thank you Chris, that is a very good explanation :-) Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |