Smalltalk › Pharo › Pharo Smalltalk Users

Timespan translateToUTC problematic

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Sean P. DeNigris

Re: Timespan translateToUTC problematic

Administrator

Pharo Smalltalk Users mailing list wrote
> #hasSameDayAs: -----------------

Wouldn't that be #isSameDayAs:?

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean

Pharo Smalltalk Users mailing list

Re: Timespan translateToUTC problematic

Oups! Didn't see that one. Yes!

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

From: Sean P. DeNigris <[hidden email]>
To: [hidden email]
Sent: Tuesday, November 21, 2017 9:14 PM
Subject: Re: [Pharo-users] Timespan translateToUTC problematic

Pharo Smalltalk Users mailing list wrote
> #hasSameDayAs: -----------------

Wouldn't that be #isSameDayAs:?

-----
Cheers,

Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Ben Coman

Re: Timespan translateToUTC problematic

In reply to this post by alistairgrant

On 22 November 2017 at 01:07, Alistair Grant <[hidden email]> wrote:

On 20 November 2017 at 09:16, Sven Van Caekenberghe <[hidden email]> wrote:
>
> 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, I think changing things now will be quite a bit of work.

However there are a couple of things we can do to make life a bit easier:

1. Add a method that facilitates TZ independent comparisons.
2. Add a bit more information in the class comments.

I've named the method #dmyEquals: below, although I don't particularly
like it. If anyone has a better idea, please reply.

how about #localEquals:

i.e. local ==> ignore timezones

btw, now we should move to discuss the default date format?

https://xkcd.com/1179/

;)-ben==

alistairgrant

Re: Timespan translateToUTC problematic

In reply to this post by alistairgrant

On 21 November 2017 at 18:07, Alistair Grant <[hidden email]> wrote:
>
> If I don't hear back in a couple of days I'll submit a PR (with
> automated tests).

Thanks to Ben, Benoit and Sven for their input.

I ended up using #equals: as suggested by Sven. I'd thought of this
and had originally rejected it due to it being the same name (when
spoken) as #=. But I've also added the other corresponding
comparisons, and #equals: fitted in the best.

Issue: https://pharo.fogbugz.com/f/cases/20747/
PR: https://github.com/pharo-project/pharo/pull/544

Cheers,
Alistair

alistairgrant

Re: Timespan translateToUTC problematic

In reply to this post by Pavel Krivanek-3

On 16 November 2017 at 20:23, Pavel Krivanek <[hidden email]> wrote:
> I openend an issue:
> https://pharo.fogbugz.com/f/cases/20700/translateToUTC-does-not-work-on-Month-and-Year
>
> Thank you for reporting
> -- Pavel

PR: https://github.com/pharo-project/pharo/pull/545

Cheers,
Alistair

> 2017-11-16 18:36 GMT+01:00 Trussardi Dario Romano
> <[hidden email]>:
>>
>> Ciao,
>>
>> i have a Pharo 4.0 image run on macbook with time zone is set to
>> Rome +1 UTC .
>>
>> When i send the translateToUTC to Date instance it is ok:
>>
>> Date today > 2017-11-16T00:00:00+01:00
>>
>> Date today translateToUTC >
>> 2017-11-16T00:00:00+00:00
>>
>>
>> But for Month instance :
>>
>> Month month: 6 year: 2015 >
>> 2015-06-01T00:00:00+01:00
>>
>> ( Month month: 6 year: 2015 ) translateToUTC >
>> 2015-06-01T00:00:00+01:00
>>
>> The same problematic is for Year instance.
>>
>> Considerations ?
>>
>> Thanks,
>>
>> Dario
>
>

Stephane Ducasse-3

Re: Timespan translateToUTC problematic

Thanks you all for this discussion.
Last time I used Date and friends I got really frustrated. The
navigation between the concept was not really good.
I needed for example to manipulate a month in a year: February 2017 (I
should check what I did).
If I would have time and money I would
- create a minimal package private only used by the kernel to load and
save image and order changesets.
- create a nicer package that we can use for app dev.

Stef

On Sat, Nov 25, 2017 at 11:54 AM, Alistair Grant <[hidden email]> wrote:

> On 16 November 2017 at 20:23, Pavel Krivanek <[hidden email]> wrote:
>> I openend an issue:
>> https://pharo.fogbugz.com/f/cases/20700/translateToUTC-does-not-work-on-Month-and-Year
>>
>> Thank you for reporting
>> -- Pavel
>
> PR: https://github.com/pharo-project/pharo/pull/545
>
> Cheers,
> Alistair
>
>
>> 2017-11-16 18:36 GMT+01:00 Trussardi Dario Romano
>> <[hidden email]>:
>>>
>>> Ciao,
>>>
>>> i have a Pharo 4.0 image run on macbook with time zone is set to
>>> Rome +1 UTC .
>>>
>>> When i send the translateToUTC to Date instance it is ok:
>>>
>>> Date today > 2017-11-16T00:00:00+01:00
>>>
>>> Date today translateToUTC >
>>> 2017-11-16T00:00:00+00:00
>>>
>>>
>>> But for Month instance :
>>>
>>> Month month: 6 year: 2015 >
>>> 2015-06-01T00:00:00+01:00
>>>
>>> ( Month month: 6 year: 2015 ) translateToUTC >
>>> 2015-06-01T00:00:00+01:00
>>>
>>> The same problematic is for Year instance.
>>>
>>> Considerations ?
>>>
>>> Thanks,
>>>
>>> Dario
>>
>>
>