s/zone/offset #1779

Closed
icambron opened this Issue Jul 17, 2014 · 30 comments

Projects

None yet

10 participants

@icambron
Member

While we're deprecating and renaming things, maybe it's time to be consistent with our use of "zone" and "offset"? I'm kind of tired of explaining that moment.zone() isn't quite what it says on the tin, and I'm almost sure @mj1856 is too. What do you think, @ichernev?

@ichernev
Contributor

To be honest I don't know what is the correct definition of zone. It might be an offset, or a complete ruleset of offsets. When you say EET (Eastern European Time), that is considered a timezone (http://www.timeanddate.com/library/abbreviations/timezones/eu/eet.html), but in fact its an offset-zone -- It changes to EEST (Easter Europen Summer Time).

The rules for when to use which is not called a zone (http://www.timeanddate.com/time/change/greece/athens for example). Its more like when to change zones because of DST.

So I'd name them zone and DSTRules. What about other libraries?

Also moment-timezone handles just that -- DST for different countries. So it should be named moment-dst if anything :) Well it also has the information about different timezones (like EET), but that is not the main thing.

@icambron
Member

I agree about the named-offset-vs-DST-rules ambiguity, but Moment doesn't support either of those, just a numerical offset. So it still seems like we should switch to the nice, unambiguous concept of "offset", whether perhaps you could really call it a "zone" or not.

The complication, I guess, is that it is actually also switching the zone DSTRuleset, since it switches to UTC DST rules (i.e. none). For big countries like the US, that actually matters, in the sense that it's reasonable to ask for a relative offset but keep the local DST rules, which in principle Moment proper can support. But whether or not that's actually a good idea, it makes it a lot easier to talk about when we frame it as " Moment supports two sets of rules, UTC and the one you're in. You can set the offset from UTC; we don't yet support offsets from the local rules". That nomenclature gets totally boned when we call the UTC offset method "zone".

The real answer is of course to get rid of DSTs.

@icambron
Member

In fact, it might be wiser to rename zone to utcOffset to make it clear that it really means "switch to UTC rules and then apply this offset". Later if we want to add localOffset(), we can.

@timrwood
Member

+1 for switching to offset.

@ichernev
Contributor

So right now there are 3 functions for dealing with these. utc (switches to UTC zone), local (switches to local zone) and zone (switches to a fixed utc offset, 0 is the same as utc(), but that is an implementation detail).

So renaming zone to utcOffset or even fixedUTCOffset is good. Also we need getters, once and for all (not tell people to check _isUTC ... insanity). isLocal, isUTC, isUTCOffset, where we should decide how to handle utcOffset == 0 (maybe depending on how you set it).

@mj1856
Member
mj1856 commented Jul 19, 2014

Yeah - I've probably been one of the more vocal ones on the interwebs about "Time Zone != Offset".... :)

From a technical perspective, I think the term "time zone" is a bit ambiguous. It could be used to describe any of:

  • Pacific Time (PT)
  • Pacific Standard Time or Pacific Daylight Time (PST / PDT)
  • UTC-8 or UTC-7
  • "America/Los_Angeles"

From a practical perspective though, I've been encouraging others to choose their words more carefully. I probably get this from DDD practices, where ubiquitous language is a key concept.

IMHO, the term "time zone" should be used for describing the entire geographic area, such that they apply without regard to any particular point in time. So "Pacific Time" or "PT" are appropriately called "time zones". So might "America/Los_Angeles" be called a "time zone", but also might be more specifically called a "time zone identifier".

I try to always call values like UTC-8 either an "offset", or a "time zone offset", and call out that a single "time zone" may have one or more "offsets" in their annual usage, or in their history.

Values like "Pacific Standard Time" (PST) are a bit trickier from a naming perspective. I think the best term I've heard for these is "time zone segment".

I do agree though - if you're making breaking changes, rename zone to offset. It's more accurate.

@icambron
Member

Getting OT, but the terminology I prefer is that PST is a "named offset"; i.e. it's just an alias for UTC-8 with a somewhat useful name that also implies that you're in PT. I agree that PT is a zone for the same reason you do, but of course it's a) an ambiguous name and b) not amenable to change (what do we call it when SF decides to have its own time zone?). America/Los_Angeles as "time zone identifier" seems fine, but I also don't mind just calling it a zone, since it's the unambiguous name for a set of rules.

Edit: another way to put that is that PT is a "common name" for America/Lost_Angeles.

@timrwood
Member

This would also be the perfect time to fix this issue. moment/moment-timezone#56 (comment)

Because .offset will be a new method, anyone still using .zone can get a deprecation message noting that the new method and that the sign would now be consistent between passing a string or a number.

@mj1856
Member
mj1856 commented Jul 21, 2014

Agreed about #56.

@ichernev
Contributor

OK, so how about:

  • do not touch the existing zone behavior, just make sure its deprecated :)
  • introduce utcOffset getter and setter. It would not invert as zone used to. It should also handle minute, hour and string offsets (utcOffset(1) === utcOffset(60) === utcOffset("+1:00"))
  • introduce isLocal, isUtc and isUtcOffset. isUtc is a shorthand for isUtcOffset() && utcOffset() === 0.
  • [later] if we put named-utc-offset information in moment (to handle Date.toString() parsing), we can support utcOffset("PDT"), or even have moment.parseUtcOffset() that just takes offset input and canonicalize it (to minutes).

Note: Not sure if we should use UTC of Utc, but the existing methods are called utc, not UTC, so it makes sense to capitalize Utc ... ugh.

@timrwood
Member

@ichernev, that all looks good to me.

We may want to fn.isUTC = fn.isUtc for developer friendliness.

EST as a named alias for -04:00 might be a little trickier as Australia also has an Eastern Standard Time and Eastern Saving Time.

@ichernev
Contributor

According to this there is no EST in Australia.

@timrwood
Member

See moment/moment-timezone#108 and eggert/tz@62df86e#diff-7a413a97538e4a2a88ec6c08dd067830R869.

They are changing, but that's just one example of a name not being unique to a offset. I haven't checked other named offsets, but I'm guessing it happens in other places as well.

@icambron
Member

I agree with @timrwood - I don't think we can depend on these being unique. See e.g. BST and BST. There are a bunch CSTs (the US's, Cuba's, China's); just scan this list. It's not even clear to me that there's a real governing standard for this stuff.

@ichernev ichernev added the Deprecate label Jul 29, 2014
@ichernev ichernev added this to the 2.9 milestone Aug 5, 2014
@ichernev ichernev added the todo label Oct 25, 2014
@ichernev
Contributor

Close in favor of #2074

@ichernev ichernev closed this Dec 28, 2014
@KATT KATT added a commit to KATT/node-cron that referenced this issue Jan 20, 2015
@KATT KATT update moment-timezone
get rid of deprecation warning `Deprecation warning: moment().zone is deprecated, use moment().utcOffset instead. moment/moment#1779`
881e8bc
@KATT KATT added a commit to KATT/node-cron that referenced this issue Jan 20, 2015
@KATT KATT update moment-timezone
get rid of deprecation warning "Deprecation warning: moment().zone is deprecated, use moment().utcOffset instead. moment/moment#1779"
2cd877c
@KATT KATT referenced this issue in kelektiv/node-cron Jan 20, 2015
Merged

update moment-timezone #135

@RumataEstor

Now we have moment().utcOffset() == - moment.tz.zone( <your local zone id> ).offset(moment()).

@YidingW YidingW pushed a commit to YidingW/bootstrap-daterangepicker that referenced this issue Feb 5, 2015
Yiding Update moment.js and zone()
Update moment.js to the latest;
According to moment/moment#1779, change zone()
to utcOffset()
af028d4
@AlmogRnD

Hi everyone,
I'm getting this error message but I'm not using moment zone I have

moment().subtract(7, 'days')
moment().add(18, 'h')
moment().startOf('month')
moment().endOf('month')

Why am I getting the error message

@kashifshamaz21

@almogdesign Can you add the error you are getting? Dont see any issue with those api calls.

@AlmogRnD

@kashifshamaz21 here it is
Deprecation warning: moment().zone is deprecated, use moment().utcOffset instead. #1779

function printMsg(msg) {
if (moment.suppressDeprecationWarnings === false &&
typeof console !== 'undefined' && console.warn) {
console.warn('Deprecation warning: ' + msg);
}
}

@kashifshamaz21

@almogdesign I ran all 4 APIs you mentioned, on moment 2.9.0, and didn't see any deprecation warning, as expected.
The deprecation warning is shown only when moment().zone() is invoked.
Can you double check, you aren't invoking that call in your flow. A JSFiddle would help if you still face the issue without any zone() API calls being triggered.

@quickstep25

Strangely enough, I am getting the same result on my local app, but I cannot reproduce in my JSFiddle.

However, I am using Moment.Timezone but not making any calls to it directly, but other third party scripts I am using might be from just a couple lines of code.
Using:

  • Moment 2.9.0
  • Timezone 0.3.0

Code is simple enough:

$(function () {

    var initDate = function (arrears) {
        return {
            startDate: moment().subtract(arrears, 'days').format('YYYY-MM-DD'),
            endDate: moment().subtract(arrears, 'days').format('YYYY-MM-DD')
        };
    };
    console.log(initDate(6));
});
/* JSFIDDLE is not producing the warnings as seen on local.  Expected Results: 
    - Deprecation warning: Accessing Moment through the global scope is deprecated, and will be removed in an upcoming release.
    - Deprecation warning: moment().zone is deprecated, use moment().utcOffset instead. https://github.com/moment/moment/issues/1779.
*/    

The warnings aren't causing any issues for me, just wanted to add to the investigation as I have not put energy into tracking the warnings down yet.

The other libraries I mentioned above as the possible culprits are:

So I highly, I suspect daterangepicker is using the timezone in some fashion....

Not sure if that helps but in @almogdesign case, perhaps another library is causing the warnings to popup at the first usage of moment.

@AlmogRnD

Yes I'm also using daterangepicker.js which I think is casing the issue

@carldanley carldanley referenced this issue in kelektiv/node-cron Feb 24, 2015
Merged

Fixes the deprecation notice from moment. #148

@quickstep25

I just noticed this evening what the problem which you have already pointed out. :)

I updated daterangepicker to the new release. 1.3.18 which has those fixes contained within, and I no longer have the warnings from moment.js

@AlmogRnD

Thanks

@marqu3s marqu3s added a commit to marqu3s/fullcalendar that referenced this issue Jun 12, 2015
@marqu3s marqu3s Update moment-ext.js
Remove Deprecation warning: moment().zone is deprecated, use moment().utcOffset instead.
moment/moment#1779
7642642
@marqu3s marqu3s referenced this issue in ChurchDesk/fullcalendar Jun 12, 2015
Merged

Update moment-ext.js #4

@samholmes

Deprecation warning: moment().zone is deprecated, use moment().utcOffset instead. #1779

This is the message I get when running my app. I don't use the zone method at all in my app, so why am I getting a warning about it?

@mj1856
Member
mj1856 commented Jun 16, 2015

@samholmes - hard to say without seeing an example. Perhaps you have some other dependency that uses it? If you can post a jsFiddle or similar that reproduces the message, I'd be happy to investigate. Otherwise, dive in to your browser's debugging tools and check the stack trace to see what's making the call to that function.

@samholmes
$ npm list moment
SECRET@0.0.0 /Users/holmes/Code/SECRET/app
├─┬ cron@1.0.6
│ └─┬ moment-timezone@0.2.4
│   └── moment@2.9.0 
└── moment@2.9.0 

Is this a 2.9.0 problem?

@mj1856
Member
mj1856 commented Jun 17, 2015

@samholmes - This looks like the same as moment/moment-timezone#228. I see you're using moment-timezone 0.2.4. I can also see that cron 1.0.6 took a hard dependency on moment-timezone version 0.2.4, but in the current version it asks for "~0.3.0" - which I understand to mean >= 0.3.0 and < 1.0.0.

Therefore, updating to the latest cron and moment versions should fix the issue.

@robertdumitrescu

I changed the the zone to utcOffset in my implementation but I still get the deprecation error. What can I do to avoid that. I made sure that aren't any .zone() calls in my implementatioin.

@mj1856
Member
mj1856 commented Feb 8, 2016

@robertdumitrescu search your code. Or put it somewhere we can search and give a URL. Not sure what else I could suggest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment