> On 17.02.2016, at 23:59, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> 
> Hi Chris,
> 
> there is no need that Timespan class>>current calls #nowWithOffset:.

It doesn’t. I changed that. Oh. Chris changed it back.

I had all the Chronology tests green, now TimespanTest>>testCurrent is failing again. I spent a couple hours yesterday making it all work.

Chris, please make the tests green again (without mucking around with the tests). Easiest would be to revert Timespan class>>current to my version.

> We
> should not suggest that we make actual use of aDuration if we do not. ;-)
> The API #nowWithOffset:, should stay in place for backwards compatibility.

If any we should deprecate it. It does not make sense. It’s as short to write “(… now offset: …)” with exactly the same (wrong) result. If it answered the same time (now) in a different timezone that would be okay, but that’s not what it does (that would be “… now utcOffset: …”. It does not give you “now” at all.

I did experiment with that, which is why the “now:offset:” method exists at all, but it would better be folded back into #now as the only entry point.

As I explained yesterday, Timespan uses its “defaultOffset” as a wildcard to mean “ignore the timezone” so any mucking around with the offset should be local to Timespan and not spill over into DateAndTime.

David is looking into rewriting Chronology to actually make sense, but this may take a while. For now we’ll have to live with this design.

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4207 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160218/6d4d8c23/smime-0001.bin