November 2017 - Pharo-users

Re: [Pharo-users] New Pharo article at The Cohort

by Andrew Glynn

The amount of FUD spread by M$ and IBM, just two very noticeable examples out of numerous others, is possible because very few of those laws are applicable unless the statement is part of a paid campaign by the originating company. If I exaggerate how well my MB 400E was made on a blog post, neither I nor MB are likely to run into any legal issues. If MB does so in an advertisement, it becomes a different matter. That said, I donât think merit is really in question. There are two bigger ones: 1. To whose advantage is inefficient development and the tooling that promotes it? 2. How would people who find it too difficult to maintain state in a single threaded language acclimatize themselves to Pharo Smalltalk (or to any actual programming language, for that matter) ? The first question doesnât have one answer, since itâs to the advantage of a number of interested parties, from large organizations that can afford inefficiency more than smaller competitors (and simultaneously can afford the not inconsequential investment in writing a proprietary Smalltalk or something similar for things that âmust workâ), to click-bait online âforumsâ such as âSlack Overloadâ. The second, well, I suppose how you would answer it depends on your experience working with said people. My own hasnât been particularly positive. Not that Iâm particularly enamoured with the idea of Pharo becoming mainstream. It would then be subject to the same disruption as current mainstream environments. The degradation of Java environments over the past 20 years is a good example. It was never great, but the combination of syntactic parmesan to hide the bad spaghetti and the need to support every passing fad has made it nearly unusable. Iâve seen a number of companies specifying Java 7 or even Java 6 in their tech stacks âbecause Java 8 is too unreliableâ. Until mainstream âsoftware engineersâ start acting like engineers, i.e. people who make things work, rather than popularity contestants or fashion victims, that wonât change. Andrew Glynn From: Richard A. O'Keefe Sent: Sunday, November 19, 2017 6:19 PM To: Pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] New Pharo article at The Cohort I'm obviously missing a lot of the context here, but in my country (New Zealand) there is something called the Fair Trading Act. My understanding from reading the Commerce Commission web site is that - false or misleading representations about goods or services or the availability of goods are against the law - "The penalties for breaching the Act can be severe" (Grant Harris). - obviously wild exaggerations made to be funny are sort of OK, but if anyone falls for them you could find this tested in court - "Any claims made to bolster the image of a business or its products or services must be accurate." - "The Act applies even when there was no intention to breach the Act". (Grant Harris again.) http://www.comcom.govt.nz/fair-trading/fair-trading-act-fact-sheets/claimin… The Fair Trading Act was passed as part of a program of market liberalisation and in order to foster competition and market efficiency, and the majority of the cases have been trader-to- trader. Why mention this? Because it's not just places where consumer protection is high-ranked that have such laws; it's also places that are gung-ho about free markets and competition and want to protect businesses. Law in the USA varies from state to state. For California, see https://www.truthinadvertising.org/california/ (which has a navbar on the right for other states). Me, I think Pharo is good enough to "sell" on its merits without any exaggerations. (If you could combine the great looks of Dolphin Smalltalk with the great features of Pharo, drool...)

Nov. 20, 2017

Re: [Pharo-users] New Pharo article at The Cohort

by horrido

Fortunately, I'm not selling a product, good or service. I'm selling an idea. The idea that you should use Pharo for software development. This isn't about commerce or trade, and thus there can be no basis for litigation. I'm rather amused that everyone has missed the fundamental point, which I made long ago at the start of my campaign: *I'm adopting marketing techniques or practices to promote Smalltalk.* That's not to say that I'm marketing a good or service, so whatever laws there are, they don't apply. I'm just borrowing a method to *raise public awareness*. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Pavel Krivanek

In any case, we have an issue because the behavior of the Date and Month is different -- Pavel 2017-11-20 9:16 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 20 Nov 2017, at 07:58, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> > >> > >>> On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >>> > >>> On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>> Both interpretation are correct and valid, it is just hard to capture > them with one class. > >>>> > >>>> In normal human conversation and in the abstract, of course a date is > just a year/month/date triple. But that is because most people only look at > this from their own perspective. However, from an international > perspective, of course it must include time zone info. Remember > end-of-year/new-year, with all those articles about people in other > countries partying or having fireworks earlier/later. > >>>> > >>>> Date transitions are different in each time zone, so to talk > accurately about a date, you need the context of a time zone. > >>> > >>> I don't think this is correct. > >>> > >>> If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight > >>> to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST > >>> Australia is one day ahead. > >>> > >>> How can this be interpreted sensibly given only a date? Unless I'm > >>> missing something, I think Peter is correct and that a Date shouldn't > >>> have any concept of timezone. > >> > >> Inspect and compare the following two Dates: > >> > >> { > >> (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. > >> (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate > >> }. > >> > >> This is as if you typed 'Date today' at the beginning of next January > 1st in your timezone or mine. Both print as '1 January 2018'. In some sense > they are equal (the abstract, context free view), but as a timespan > [start,stop] interval they are different, they do not include the same > points in time. By having the timezone in there, the ambiguity is resolved. > That is because the exact start moment is different: > >> > >> { > >> (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. > >> (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC > >> }. > > > > Sven, thanks for your reply. I haven't thought about this as much as > > Richard, but came to the same conclusion. > > > > I think your comment about being equal "in the abstract, context free > > view" gets to the core of the issue. > > > > A date can be abstract, i.e. just a day, month and year, or it can be > > a timespan (a 24 hour period starting at a particular timezone). We > > may know the appropriate timezone when we specify the date, or we may > > not know until we want to use the date. > > > > As an example, take wishing someone happy birthday. I want to know > > that person's birthday in the abstract. Each year I will want to > > apply it with timezones, i.e. I'll figure out an appropriate time to > > contact them given my timezone and their's. Figuring out when to > > contact them certainly doesn't depend on the timezone I was in when I > > recorded their birthday, or the timezone they were in when they were > > born. If I want to know if that person and I have the same birthday, > > I won't be taking timezones into account. > > Well, that example is exactly why you do need the TZ (in the date or not > is another matter). If I, from my TZ, want to be the first to wish you a > happy birthday, I have to know your exact TZ. > > We can discuss about this ad infinitum. I think we all agree that there > are 2 views (abstract calendar date and concrete time interval/span, which > requires a TZ), as well as 2 possible ways to deal with the second case (TZ > inside date or as context outside of the date). > > Right now, it is TZ inside, but you are free to ignore it. That is how it > is, I did not write it, I would probably do it differently myself, but I > don't think there is a bug, nor that we have to change it any time soon. > > There are several alternative packages out there, and everyone can write > their own, maybe one will eventually become the most popular as to be the > default in the image, but I doubt it. > > > Google Calendar has (had?) exactly this problem. I entered an all day > > event as a reminder for someone's birthday. When the day came I > > happened to be in a different timezone and their birthday was from 4pm > > one day to 4pm the next. I don't remember which timezone I was in > > when I added the event, and I'm certainly not interested in figuring > > it out. Which of the two dates covered by this "one date" is > > the correct one? > > > > It should be easy to convert an abstract date to a concrete date, i.e. > > one with a specified timezone, but I think they are two different > > concepts. > > > > Thanks! > > Alistair > > > > > > > > > >> BTW, my ZTimestamp package is an alternative DateAndTime object that is > (1) always in UTC, and thus contains no timezone and (2) has second > precision. It is half the size and faster to work with. > >> > >> By using its accompanying ZTimezone class that loads the Olsen DB, you > do the necessary conversions when presenting to humans. That of course then > requires the context (current or applicable timezone) to be supplied > externally. > >> > >> (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now. > >> > >> HTH, > >> > >> Sven > >> > >>> Cheers, > >>> Alistair > >>> > >>> > >>>> Whether that timezone is actually part of the date object is another > discussion, but there is always the timezone context even if it is implicit > ('of course I mean my own timezone and not yours'). > >>>> > >>>>> On 17 Nov 2017, at 14:19, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>>> > >>>>> Because Date has, by definition, no concept of time. > >>>>> The only reason why you see it is because someone decided to save a > bit of time and reuse implementation. > >>>>> > >>>>> If you want to move TZ, you need something that _has_ time. Such as > DateAndTime. > >>>>> > >>>>> You can also read the comments ... > >>>>> > >>>>> Date > >>>>>> Instances of Date are Timespans with duration of 1 day. > >>>>> > >>>>> it represents an entire day, not a particular time point > >>>>> > >>>>> DateAndTime > >>>>>> I represent a point in time or timestamp as defined by ISO 8601. > >>>>>> I am TimeZone aware. > >>>>> > >>>>> I really don't understand why are you trying to force TZ into Date > against it's purpose when you have a class that does exactly what you want > and was built for that purpose. > >>>>> > >>>>> Peter > >>>>> > >>>>> On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black < > black(a)cs.pdx.edu> wrote: > >>>>> > >>>>>> On 17 Nov 2017, at 08:49 , Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>>>> > >>>>>> I find the concept of translating TZ of a Date silly. The real bug > imho should be that it prints both time and TZ.... this is Date, not > DateAndTime. > >>>>>> > >>>>> > >>>>> I live in Oregon, and frequently work with people in New Zealand, > which is (depending on the time of year) 19 to 21 hours ahead of Oregon. > So, when it is 3pm at home, it is noon the next day in New Zealand. > >>>>> > >>>>> This means that in order to know the day of the week, the month, and > even the year, of a given instant in UTC, one has to know the timezone that > is being referred to. The answer could be Sunday, 31 December 2017 for one > observer, and Monday, 1 January 2018 for another. > >>>>> > >>>>> So, contrary to your statement, I donât see how I can know the date > without also knowing the Time Zone. > >>>>> > >>>>> Andrew > > >

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Sven Van Caekenberghe

> On 20 Nov 2017, at 07:58, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Both interpretation are correct and valid, it is just hard to capture them with one class. >>>> >>>> In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later. >>>> >>>> Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone. >>> >>> I don't think this is correct. >>> >>> If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight >>> to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST >>> Australia is one day ahead. >>> >>> How can this be interpreted sensibly given only a date? Unless I'm >>> missing something, I think Peter is correct and that a Date shouldn't >>> have any concept of timezone. >> >> Inspect and compare the following two Dates: >> >> { >> (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. >> (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate >> }. >> >> This is as if you typed 'Date today' at the beginning of next January 1st in your timezone or mine. Both print as '1 January 2018'. In some sense they are equal (the abstract, context free view), but as a timespan [start,stop] interval they are different, they do not include the same points in time. By having the timezone in there, the ambiguity is resolved. That is because the exact start moment is different: >> >> { >> (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. >> (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC >> }. > > Sven, thanks for your reply. I haven't thought about this as much as > Richard, but came to the same conclusion. > > I think your comment about being equal "in the abstract, context free > view" gets to the core of the issue. > > A date can be abstract, i.e. just a day, month and year, or it can be > a timespan (a 24 hour period starting at a particular timezone). We > may know the appropriate timezone when we specify the date, or we may > not know until we want to use the date. > > As an example, take wishing someone happy birthday. I want to know > that person's birthday in the abstract. Each year I will want to > apply it with timezones, i.e. I'll figure out an appropriate time to > contact them given my timezone and their's. Figuring out when to > contact them certainly doesn't depend on the timezone I was in when I > recorded their birthday, or the timezone they were in when they were > born. If I want to know if that person and I have the same birthday, > I won't be taking timezones into account. Well, that example is exactly why you do need the TZ (in the date or not is another matter). If I, from my TZ, want to be the first to wish you a happy birthday, I have to know your exact TZ. We can discuss about this ad infinitum. I think we all agree that there are 2 views (abstract calendar date and concrete time interval/span, which requires a TZ), as well as 2 possible ways to deal with the second case (TZ inside date or as context outside of the date). Right now, it is TZ inside, but you are free to ignore it. That is how it is, I did not write it, I would probably do it differently myself, but I don't think there is a bug, nor that we have to change it any time soon. There are several alternative packages out there, and everyone can write their own, maybe one will eventually become the most popular as to be the default in the image, but I doubt it. > Google Calendar has (had?) exactly this problem. I entered an all day > event as a reminder for someone's birthday. When the day came I > happened to be in a different timezone and their birthday was from 4pm > one day to 4pm the next. I don't remember which timezone I was in > when I added the event, and I'm certainly not interested in figuring > it out. Which of the two dates covered by this "one date" is > the correct one? > > It should be easy to convert an abstract date to a concrete date, i.e. > one with a specified timezone, but I think they are two different > concepts. > > Thanks! > Alistair > > > > >> BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) always in UTC, and thus contains no timezone and (2) has second precision. It is half the size and faster to work with. >> >> By using its accompanying ZTimezone class that loads the Olsen DB, you do the necessary conversions when presenting to humans. That of course then requires the context (current or applicable timezone) to be supplied externally. >> >> (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now. >> >> HTH, >> >> Sven >> >>> Cheers, >>> Alistair >>> >>> >>>> Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours'). >>>> >>>>> On 17 Nov 2017, at 14:19, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>>> >>>>> Because Date has, by definition, no concept of time. >>>>> The only reason why you see it is because someone decided to save a bit of time and reuse implementation. >>>>> >>>>> If you want to move TZ, you need something that _has_ time. Such as DateAndTime. >>>>> >>>>> You can also read the comments ... >>>>> >>>>> Date >>>>>> Instances of Date are Timespans with duration of 1 day. >>>>> >>>>> it represents an entire day, not a particular time point >>>>> >>>>> DateAndTime >>>>>> I represent a point in time or timestamp as defined by ISO 8601. >>>>>> I am TimeZone aware. >>>>> >>>>> I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose. >>>>> >>>>> Peter >>>>> >>>>> On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: >>>>> >>>>>> On 17 Nov 2017, at 08:49 , Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>>>> >>>>>> I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime. >>>>>> >>>>> >>>>> I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand. >>>>> >>>>> This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another. >>>>> >>>>> So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone. >>>>> >>>>> Andrew

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Alistair Grant

On 20 November 2017 at 08:30, Ben Coman <btc(a)openinworld.com> wrote: > I don't ponder much on Dates, DateTimes etc, but I just had one interesting > image flash through my head > and was curious how correct it sounds, or if I'm completely off base. > > So who remembers the old arcade game "Moon Buggy" ? > https://www.youtube.com/watch?v=6EptD9Egf7w > > Now imagine that passing beneath your wheels is a hyper-fast terrain of > DateTime . > Levels are days marked "A" , "B", "C", "D", "E" at *fixed* points on the > DateTime terrain, representing when a particular Date begins. > > As your day progresses dealing with obstacles in your path the *point* of > Date separation approaches you. > In your own timezone you know what Date it is by when your wheels pass over > a Date marker. I'm just glad that Bloc is on the way and we have GTInspector so that in future when I inspect a Date there'll be a tab there that *you* wrote with a moon buggy flashing lasers to show me what's happening. :-) > Now if someone in the US wants to know the date in New Zealand, > that is like attaching a scanning laser beam to the front of the buggy. > How far ahead it scans depends on the *difference* between time zones. > As the DateTime terrain passes beneath your wheels, the fixed Date point > approaches you, and when it touches your lazer scanner, the Date changes in > the other timezone. > > So the way to find the date in another timezone, > is not to give a Date a timezone, but rather to add the difference in > timezones to your DateTime > to get the DateTime in the target country to compare that with > timezoneless-Date. I think that there's still use for representing a date as a timespan, i.e. a 24 hour period that we can use to find the intersection of times, etc (in addition to adding a timezone offset to a DateTime to figure out the date in a different country). Whether it needs to be a separate class from Timespan I'm not so sure. Cheers, Alistair > cheers -ben > > > > > [1] https://www.youtube.com/watch?v=6EptD9Egf7w > > > On 20 November 2017 at 10:12, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >> Richard, >> >> That is a very good explanation, and 100% correct. >> >> Dave >> >> On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote: >> > I think the fundamental question is what a Date is supposed >> > to represent. I have spent a LOT of time thinking about date >> > and time classes over the last 10 years, and have come to the >> > conclusion that it makes no sense to view a Date as a Timespan. >> > >> > Let's take an example. >> > Christmas this year is going to be 2017-12-25 in every country >> > that uses the Gregorian calendar and observes Christmas at all. >> > If I ask the question >> > "Is Christmas on the same date in Utah as it is in Otago?" >> > I expect to get the answer YES. >> > But if I ask the question >> > "Is the span of time *called* Christmas day there same >> > as the span of time *called* Christmas day here?" >> > I expect to get the answer NO. >> > >> > It's not entirely unlike the way that '95 Hanover Street' >> > is the same street address in my city as '95 Hanover Street' >> > in Edinburgh, but they correspond to quite different places. >> > (Here: the Urgent Doctors; there: serviced apartments.) >> > >> > Returning to Dates, I expect something like >> > aDate asTimespan: aTimeZone >> > to return a timespan that might be 23, 24, or 25 hours >> > (possibly plus an extra second), with *maybe* >> > aDate asTimespan >> > meaning >> > aDate asTimespan: TimeZone here >> > >> > Naturally the same goes for Weeks, Months, and Years, should >> > they exist. >> > >> >

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Ben Coman

On 20 November 2017 at 14:58, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> > >> On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>> Both interpretation are correct and valid, it is just hard to capture > them with one class. > >>> > >>> In normal human conversation and in the abstract, of course a date is > just a year/month/date triple. But that is because most people only look at > this from their own perspective. However, from an international > perspective, of course it must include time zone info. Remember > end-of-year/new-year, with all those articles about people in other > countries partying or having fireworks earlier/later. > >>> > >>> Date transitions are different in each time zone, so to talk > accurately about a date, you need the context of a time zone. > >> > >> I don't think this is correct. > >> > >> If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight > >> to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST > >> Australia is one day ahead. > >> > >> How can this be interpreted sensibly given only a date? Unless I'm > >> missing something, I think Peter is correct and that a Date shouldn't > >> have any concept of timezone. > > > > Inspect and compare the following two Dates: > > > > { > > (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. > > (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate > > }. > > > > This is as if you typed 'Date today' at the beginning of next January > 1st in your timezone or mine. Both print as '1 January 2018'. In some sense > they are equal (the abstract, context free view), but as a timespan > [start,stop] interval they are different, they do not include the same > points in time. By having the timezone in there, the ambiguity is resolved. > That is because the exact start moment is different: > > > > { > > (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. > > (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC > > }. > > Sven, thanks for your reply. I haven't thought about this as much as > Richard, but came to the same conclusion. > > I think your comment about being equal "in the abstract, context free > view" gets to the core of the issue. > > A date can be abstract, i.e. just a day, month and year, or it can be > a timespan (a 24 hour period starting at a particular timezone). We > may know the appropriate timezone when we specify the date, or we may > not know until we want to use the date. > > As an example, take wishing someone happy birthday. I want to know > that person's birthday in the abstract. Each year I will want to > apply it with timezones, i.e. I'll figure out an appropriate time to > contact them given my timezone and their's. Figuring out when to > contact them certainly doesn't depend on the timezone I was in when I > recorded their birthday, or the timezone they were in when they were > born. If I want to know if that person and I have the same birthday, > I won't be taking timezones into account. > Nice examples. They made a lot of sense. > > Google Calendar has (had?) exactly this problem. I entered an all day > event as a reminder for someone's birthday. When the day came I > happened to be in a different timezone and their birthday was from 4pm > one day to 4pm the next. I don't remember which timezone I was in > when I added the event, and I'm certainly not interested in figuring > it out. Which of the two dates covered by this "one date" is the correct one? > Obviously GodGoog should know this date was associated with a particular person, and since they're happy with GG geo-tracking their location, GG should have adapted. Sounds like a bug to me. \ ;^)-cheers-ben / > > It should be easy to convert an abstract date to a concrete date, i.e. > one with a specified timezone, but I think they are two different > concepts. > > Thanks! > Alistair > > > > > > BTW, my ZTimestamp package is an alternative DateAndTime object that is > (1) always in UTC, and thus contains no timezone and (2) has second > precision. It is half the size and faster to work with. > > > > By using its accompanying ZTimezone class that loads the Olsen DB, you > do the necessary conversions when presenting to humans. That of course then > requires the context (current or applicable timezone) to be supplied > externally. > > > > (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now. > > > > HTH, > > > > Sven > > > >> Cheers, > >> Alistair > >> > >> > >>> Whether that timezone is actually part of the date object is another > discussion, but there is always the timezone context even if it is implicit > ('of course I mean my own timezone and not yours'). > >>> > >>>> On 17 Nov 2017, at 14:19, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>> > >>>> Because Date has, by definition, no concept of time. > >>>> The only reason why you see it is because someone decided to save a > bit of time and reuse implementation. > >>>> > >>>> If you want to move TZ, you need something that _has_ time. Such as > DateAndTime. > >>>> > >>>> You can also read the comments ... > >>>> > >>>> Date > >>>>> Instances of Date are Timespans with duration of 1 day. > >>>> > >>>> it represents an entire day, not a particular time point > >>>> > >>>> DateAndTime > >>>>> I represent a point in time or timestamp as defined by ISO 8601. > >>>>> I am TimeZone aware. > >>>> > >>>> I really don't understand why are you trying to force TZ into Date > against it's purpose when you have a class that does exactly what you want > and was built for that purpose. > >>>> > >>>> Peter > >>>> > >>>> On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black < > black(a)cs.pdx.edu> wrote: > >>>> > >>>>> On 17 Nov 2017, at 08:49 , Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>>> > >>>>> I find the concept of translating TZ of a Date silly. The real bug > imho should be that it prints both time and TZ.... this is Date, not > DateAndTime. > >>>>> > >>>> > >>>> I live in Oregon, and frequently work with people in New Zealand, > which is (depending on the time of year) 19 to 21 hours ahead of Oregon. > So, when it is 3pm at home, it is noon the next day in New Zealand. > >>>> > >>>> This means that in order to know the day of the week, the month, and > even the year, of a given instant in UTC, one has to know the timezone that > is being referred to. The answer could be Sunday, 31 December 2017 for one > observer, and Monday, 1 January 2018 for another. > >>>> > >>>> So, contrary to your statement, I donât see how I can know the date > without also knowing the Time Zone. > >>>> > >>>> Andrew > >>>> > >>> > >>> > >> > > > > > >

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Ben Coman

I don't ponder much on Dates, DateTimes etc, but I just had one interesting image flash through my head and was curious how correct it sounds, or if I'm completely off base. So who remembers the old arcade game "Moon Buggy" ? https://www.youtube.com/watch?v=6EptD9Egf7w Now imagine that passing beneath your wheels is a hyper-fast terrain of DateTime . Levels are days marked "A" , "B", "C", "D", "E" at *fixed* points on the DateTime terrain, representing when a particular Date begins. As your day progresses dealing with obstacles in your path the *point* of Date separation approaches you. In your own timezone you know what Date it is by when your wheels pass over a Date marker. Now if someone in the US wants to know the date in New Zealand, that is like attaching a scanning laser beam to the front of the buggy. How far ahead it scans depends on the *difference* between time zones. As the DateTime terrain passes beneath your wheels, the fixed Date point approaches you, and when it touches your lazer scanner, the Date changes in the other timezone. So the way to find the date in another timezone, is not to give a Date a timezone, but rather to add the difference in timezones to your DateTime to get the DateTime in the target country to compare that with timezoneless-Date. cheers -ben [1] https://www.youtube.com/watch?v=6EptD9Egf7w On 20 November 2017 at 10:12, David T. Lewis <lewis(a)mail.msen.com> wrote: > Richard, > > That is a very good explanation, and 100% correct. > > Dave > > On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote: > > I think the fundamental question is what a Date is supposed > > to represent. I have spent a LOT of time thinking about date > > and time classes over the last 10 years, and have come to the > > conclusion that it makes no sense to view a Date as a Timespan. > > > > Let's take an example. > > Christmas this year is going to be 2017-12-25 in every country > > that uses the Gregorian calendar and observes Christmas at all. > > If I ask the question > > "Is Christmas on the same date in Utah as it is in Otago?" > > I expect to get the answer YES. > > But if I ask the question > > "Is the span of time *called* Christmas day there same > > as the span of time *called* Christmas day here?" > > I expect to get the answer NO. > > > > It's not entirely unlike the way that '95 Hanover Street' > > is the same street address in my city as '95 Hanover Street' > > in Edinburgh, but they correspond to quite different places. > > (Here: the Urgent Doctors; there: serviced apartments.) > > > > Returning to Dates, I expect something like > > aDate asTimespan: aTimeZone > > to return a timespan that might be 23, 24, or 25 hours > > (possibly plus an extra second), with *maybe* > > aDate asTimespan > > meaning > > aDate asTimespan: TimeZone here > > > > Naturally the same goes for Weeks, Months, and Years, should > > they exist. > > > >

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Alistair Grant

On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Both interpretation are correct and valid, it is just hard to capture them with one class. >>> >>> In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later. >>> >>> Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone. >> >> I don't think this is correct. >> >> If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight >> to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST >> Australia is one day ahead. >> >> How can this be interpreted sensibly given only a date? Unless I'm >> missing something, I think Peter is correct and that a Date shouldn't >> have any concept of timezone. > > Inspect and compare the following two Dates: > > { > (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. > (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate > }. > > This is as if you typed 'Date today' at the beginning of next January 1st in your timezone or mine. Both print as '1 January 2018'. In some sense they are equal (the abstract, context free view), but as a timespan [start,stop] interval they are different, they do not include the same points in time. By having the timezone in there, the ambiguity is resolved. That is because the exact start moment is different: > > { > (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. > (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC > }. Sven, thanks for your reply. I haven't thought about this as much as Richard, but came to the same conclusion. I think your comment about being equal "in the abstract, context free view" gets to the core of the issue. A date can be abstract, i.e. just a day, month and year, or it can be a timespan (a 24 hour period starting at a particular timezone). We may know the appropriate timezone when we specify the date, or we may not know until we want to use the date. As an example, take wishing someone happy birthday. I want to know that person's birthday in the abstract. Each year I will want to apply it with timezones, i.e. I'll figure out an appropriate time to contact them given my timezone and their's. Figuring out when to contact them certainly doesn't depend on the timezone I was in when I recorded their birthday, or the timezone they were in when they were born. If I want to know if that person and I have the same birthday, I won't be taking timezones into account. Google Calendar has (had?) exactly this problem. I entered an all day event as a reminder for someone's birthday. When the day came I happened to be in a different timezone and their birthday was from 4pm one day to 4pm the next. I don't remember which timezone I was in when I added the event, and I'm certainly not interested in figuring it out. Which of the two dates covered by this "one date" is the correct one? It should be easy to convert an abstract date to a concrete date, i.e. one with a specified timezone, but I think they are two different concepts. Thanks! Alistair > BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) always in UTC, and thus contains no timezone and (2) has second precision. It is half the size and faster to work with. > > By using its accompanying ZTimezone class that loads the Olsen DB, you do the necessary conversions when presenting to humans. That of course then requires the context (current or applicable timezone) to be supplied externally. > > (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now. > > HTH, > > Sven > >> Cheers, >> Alistair >> >> >>> Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours'). >>> >>>> On 17 Nov 2017, at 14:19, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> >>>> Because Date has, by definition, no concept of time. >>>> The only reason why you see it is because someone decided to save a bit of time and reuse implementation. >>>> >>>> If you want to move TZ, you need something that _has_ time. Such as DateAndTime. >>>> >>>> You can also read the comments ... >>>> >>>> Date >>>>> Instances of Date are Timespans with duration of 1 day. >>>> >>>> it represents an entire day, not a particular time point >>>> >>>> DateAndTime >>>>> I represent a point in time or timestamp as defined by ISO 8601. >>>>> I am TimeZone aware. >>>> >>>> I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose. >>>> >>>> Peter >>>> >>>> On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: >>>> >>>>> On 17 Nov 2017, at 08:49 , Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>>> >>>>> I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime. >>>>> >>>> >>>> I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand. >>>> >>>> This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another. >>>> >>>> So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone. >>>> >>>> Andrew >>>> >>> >>> >> > >

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by David T. Lewis

Richard, That is a very good explanation, and 100% correct. Dave On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote: > I think the fundamental question is what a Date is supposed > to represent. I have spent a LOT of time thinking about date > and time classes over the last 10 years, and have come to the > conclusion that it makes no sense to view a Date as a Timespan. > > Let's take an example. > Christmas this year is going to be 2017-12-25 in every country > that uses the Gregorian calendar and observes Christmas at all. > If I ask the question > "Is Christmas on the same date in Utah as it is in Otago?" > I expect to get the answer YES. > But if I ask the question > "Is the span of time *called* Christmas day there same > as the span of time *called* Christmas day here?" > I expect to get the answer NO. > > It's not entirely unlike the way that '95 Hanover Street' > is the same street address in my city as '95 Hanover Street' > in Edinburgh, but they correspond to quite different places. > (Here: the Urgent Doctors; there: serviced apartments.) > > Returning to Dates, I expect something like > aDate asTimespan: aTimeZone > to return a timespan that might be 23, 24, or 25 hours > (possibly plus an extra second), with *maybe* > aDate asTimespan > meaning > aDate asTimespan: TimeZone here > > Naturally the same goes for Weeks, Months, and Years, should > they exist. >

Nov. 20, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Richard A. O'Keefe

I think the fundamental question is what a Date is supposed to represent. I have spent a LOT of time thinking about date and time classes over the last 10 years, and have come to the conclusion that it makes no sense to view a Date as a Timespan. Let's take an example. Christmas this year is going to be 2017-12-25 in every country that uses the Gregorian calendar and observes Christmas at all. If I ask the question "Is Christmas on the same date in Utah as it is in Otago?" I expect to get the answer YES. But if I ask the question "Is the span of time *called* Christmas day there same as the span of time *called* Christmas day here?" I expect to get the answer NO. It's not entirely unlike the way that '95 Hanover Street' is the same street address in my city as '95 Hanover Street' in Edinburgh, but they correspond to quite different places. (Here: the Urgent Doctors; there: serviced apartments.) Returning to Dates, I expect something like aDate asTimespan: aTimeZone to return a timespan that might be 23, 24, or 25 hours (possibly plus an extra second), with *maybe* aDate asTimespan meaning aDate asTimespan: TimeZone here Naturally the same goes for Weeks, Months, and Years, should they exist.

Nov. 19, 2017