Thanks +Sam Vilain for offering me the opportunity to explain why always anchoring time to UTC is

Thanks +Sam Vilain for offering me the opportunity to explain why always anchoring time to UTC is the wrong answer :-)

While it is sometimes OK to anchor historical date/time data to a specific UTC offset, the anchoring breaks down for future events, so be aware that you are throwing away information when you do that.

My weekly meeting, which is anchored to Tuesdays at 17:00 in the America/New_York timezone, may occur for me at 09:00 in New Zealand, or at 11:00 (or maybe even at 10:00), so I can't anchor it to a UTC offset and must anchor it to a timezone.

So what should the "default" be?  For 'now()' the ideal answer would be that it should be (a) the current clock time, plus (b) the current timezone.  And I don't mean a UTC reference, I mean the actual current timezone, because otherwise you are dropping information that is useful.

When you handed me that 'now()' you do not know that my next calculation will be "add six months to that" and you are forcing me to jump through flaming hoops not to introduce an error - only my intention could decide that, so it must be necessary for me to be able to specifically indicate my intention among the three possibilities:

* I want this bound to the clock time in the starting timezone
* I want this bound to the clock time in a different timezone (e.g. UTC).
* I want this bound to the clock time, in all timezones (floating).

To my mind that binding should be able to be applied during the delta operation, but the default binding in the creation of the initial variable should be to the starting timezone.  Many libraries default to that third option, but adding the UTC offset is not a broadly useful solution: sometimes you do actually need that timezone.