- Pharo-users - lists.pharo.org

Re: [Pharo-users] Timezone offset in Date, why?

by Stephan Eggermont

On 03/06/15 22:21, Esteban A. Maringolo wrote: > 2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: >> For performance reasons you'll probably often want to map to smallint value objects. > > And lose the date abstraction the database provides me with? It is up > to the database how to optimize the store of its datatypes. Uhm, no on the smalltalk side. A DateAndTime is large and slow. Stephan

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Esteban A. Maringolo

2015-06-03 17:20 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 03/06/15 20:15, Esteban A. Maringolo wrote: >> >> I refer Postgres datatypes because I find them to have a good criteria >> based on a huge user base and because is what raised the issue I'm >> dealing with now. > I like the work by Richard Snodgrass. > His "Developing Time-Oriented Database Applications in SQL" is > available here: > http://www.cs.arizona.edu/~rts/publications.html Thank you! Looks very interesting. Esteban

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Esteban A. Maringolo

2015-06-03 15:36 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 03-06-15 20:15, Esteban A. Maringolo wrote: >> >> I refer Postgres datatypes because I find them to have a good criteria >> based on a huge user base and because is what raised the issue I'm >> dealing with now. > > > SQL databases are well-known to have ignored the standards for > dealing with times and dates for decades to make it difficult to > switch to a competitor. Sorry, but never heard of this intentional ignorance, particularly coming from PostgreSQL. Nonetheless, I had to deal with stupid issues in Oracle 7i-11g, but that's another story. Regarding standards, I mentioned the ISO 8601 where I haven't seen a case where a plain date comes with a timezone offset. > For performance reasons you'll probably often want to map to smallint value objects. And lose the date abstraction the database provides me with? It is up to the database how to optimize the store of its datatypes. Regards! Esteban A. Maringolo

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Stephan Eggermont

On 03/06/15 20:15, Esteban A. Maringolo wrote: > I refer Postgres datatypes because I find them to have a good criteria > based on a huge user base and because is what raised the issue I'm > dealing with now. I like the work by Richard Snodgrass. His "Developing Time-Oriented Database Applications in SQL" is available here: http://www.cs.arizona.edu/~rts/publications.html Stephan

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Esteban A. Maringolo

2015-06-03 16:13 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> But is unnecesary heretic. Date is a "calendar date", not a point in >> time. "May 3rd" is the same "date" as "May 3rd" whether you are in >> Sydney or Houston. >> ps: ISO 8601 doesn't mention anything about "date" timezones. In fact >> the word "timezone" implies time, not date. > I understand your POV, but you should have read what I originally wrote: the Date that we have now is more than an abstract date, it is an object that can answer to certain messages, like tell you when it starts, ends, whether it contains certain points in time. In order to do that, you have to know in which timezone to interpret it in. It is more than a Date because it is a Timespan, which behaves as an interval (*). But it is "so more" than the expected date, that breaks the expectation of what a Date is for me. > Look, I am not defending the current design, I just try to explain. No need to excuse, I totally understand it. I'm just ranting a little. > And May 3rd, interpreted as a concrete period of time, [from,to], is *NOT* the same in Sydney and Houston. (*) If you consider a date as an interval then it's right, but if you consider it an index of a discrete sequence, then it's wrong to treat it as an interval. In a sequence of integer numbers, you have 1, 2, 3... n, and there is no interval in between. If you store the "date of birth" it doesn't matter if you were born in Sidney, you wont get presents until is that date in Houston :P In my opinion what is wrong is that aDate is-an Interval. But that's how it is. So I'll "deal with it". :) Best regards. -- Esteban.

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Sergio Fedi

> Time is time. No matter "where" it happens. The theory of relativity disagrees

June 3, 2015

Re: [Pharo-users] Reddit example

by Sven Van Caekenberghe

> On 03 Jun 2015, at 20:24, <recursive68(a)gmail.com> <recursive68(a)gmail.com> wrote: > > Thanks for the pointers. I've got it working in Pharo 4 but had to change this method as I was getting a database session connection error. It appears to be losing the Glorp session, so I changed this class method thus: > > RedditDatabaseResource > login>> > "^ DefaultLogin ifNil: [ DefaultLogin := self createLogin ]" > ^ DefaultLogin := self createLogin. Hmm, it has been a while since I wrote this, looked at the code or ran it, but that should work the way it was intended. I even believe there is some auto-reconnect logic in Glorp, but I might be wrong.

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Sven Van Caekenberghe

> On 03 Jun 2015, at 20:10, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2015-06-03 12:05 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> On 03 Jun 2015, at 16:57, Ben Coman <btc(a)openinworld.com> wrote: >>> I've observed several of date/time discussions that I didn't really >>> follow all the details, but my first thought here is that Date, Time, >>> and DateAndTime are three separate concepts. Shouldn't timezones only >>> affect comparing dates if you are calculating the hours between dates? >>> Adding the concept of "starting at a specific moment in time" would >>> seem to turn a Date into a DateAndTime, which is the point where >>> timezones should have an impact. > > +1. > > Time is time. No matter "where" it happens. > > >>> For example, if you are reading a date "dd/mm/yyyy" from some database >>> field, what timezone do you assign? > >> That is indeed the (original) problem. > > Exactly. > >> But even dd/mm/yyyy in some random DB or somewhere on the internet implies a timezone, else it does not make (enough/total) sense. > > IMO, it doesn't imply a timezone. > >> Again, your date today is not equal to mine, at some point in time we are in different days, it is that simple. > > But is unnecesary heretic. Date is a "calendar date", not a point in > time. "May 3rd" is the same "date" as "May 3rd" whether you are in > Sydney or Houston. > > And for those "edge" cases where your calendar date is different from > mine we have DateAndTime, and so does the database with the Timestamp > format. > > It is the first time I have to deal with an implementation of Date > that includes a timezone offset in it. Funny is I never had to deal > with this before. > > Regards! > > Esteban A. Maringolo > > ps: ISO 8601 doesn't mention anything about "date" timezones. In fact > the word "timezone" implies time, not date. I understand your POV, but you should have read what I originally wrote: the Date that we have now is more than an abstract date, it is an object that can answer to certain messages, like tell you when it starts, ends, whether it contains certain points in time. In order to do that, you have to know in which timezone to interpret it in. Look, I am not defending the current design, I just try to explain. And May 3rd, interpreted as a concrete period of time, [from,to], is *NOT* the same in Sydney and Houston.

June 3, 2015

Re: [Pharo-users] Pharo Video Tutorial: Package Tags

by Sean P. DeNigris

Sergio Fedi wrote > If something is a tag, then you should be able to apply multiple tags to > something. > > If not, then they are, as you say, subpackages. Agreed. Actually, tags are more interesting as they would be much more valuable to users, who want a logical domain view of the system. Currently, the package tree we provide is more a Package Browser than a System Browser. And... tags are orthogonal to packages. The way we use them, sub-packages seems more correct. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Video-Tutorial-Package-Tags-tp4830133p4830290.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 3, 2015

Re: [Pharo-users] Timezone offset in Date, why?

by Stephan Eggermont

On 03-06-15 20:15, Esteban A. Maringolo wrote: > I refer Postgres datatypes because I find them to have a good criteria > based on a huge user base and because is what raised the issue I'm > dealing with now. SQL databases are well-known to have ignored the standards for dealing with times and dates for decades to make it difficult to switch to a competitor. For performance reasons you'll probably often want to map to smallint value objects. Stephan

June 3, 2015