start day of the week #134

Closed
skinnybrit51 opened this Issue Apr 24, 2012 · 31 comments

Projects

None yet

5 participants

@skinnybrit51

Would it be possible to change the standard start day of the week? EG Instead of Sunday use any other day of week.

@andrewplummer
Owner

What, like Thursday?

@skinnybrit51

In different countries the week start day is different. So any day of the week could be possible. I would expect this to have an affect on the beginningOf and endOf functions.

@andrewplummer
Owner

Really? I wouldn't.

Sunday is pretty much accepted in the Western world. I know there is a fine line of culture here -- and please look to the methods I've implemented before accusing me of being "Anglo-centric" -- but programmers follow certain conventions for our own sanity. This doesn't have to do with output but with the API itself, and I think some conventions are worth adopting. Not always, but in this case, yes.

Note that you can always do setWeekday, or even override the method itself using Sugar's own extension system:

Date.extend({
  beginningOfWeek: function() {
    return this.setWeekday(6).resetTime();
  }
}, true);

etc...

@andrewplummer
Owner

Note the second param in extend allows overriding the original.

@andrewplummer
Owner

Gonna close this out unless there's anything else...

@skinnybrit51

Sorry, hadn't got round to testing your suggestion for setting the beginning of the week. When building pure internationalized software you can not be bias to the defacto's used in the western world.

@andrewplummer
Owner

Again, what you're saying is 100% valid when talking about localization, but not when talking about a programming API. Standardization is part and parcel of what makes software easy to use, and much can be gained by it, even if it isn't always culturally sensitive.

@skinnybrit51

If the api does not provide or take into account that constants can be different then localization would not work in this case.

@andrewplummer
Owner

I don't know what you mean by that but ironically this sentence finally made me understand what you want. I think I see it in a different light now...

You're saying beginningOfWeek should take locales into account. That's starting to make a bit more sense. The problem I see with this is the murkiness of culture coming into play. Rather than beginningOfWeek, let's take beginningOfYear as an example... of course it COULD consider that to be the beginning of the lunar calendar, i.e. the Chinese New year. However this is just such a gray area as to be almost ridiculous...

Let's be more pragmatic about the problem. What locales specifically do you have in mind, when is their "beginning of the week", and how set in stone is this?

@skinnybrit51

The java calendar provides a good reference. (Hate referencing a java api when talking about js)

The two methods that are required in sugar dates are:
setFirstDayOfWeek()
setMinimalDaysInFirstWeek()

This would allow for true flexibility with regards to internationalization when date calculations are required.

I really hope this is something that can be achieved in sugar dates as the library is a clear step ahead of any others out there. This would be the icing on the cake!

@skinnybrit51

Any more thoughts on this?

@inossidabile

I could find a use for this too. The exUSSR world has a Monday as a first day of week.

@andrewplummer
Owner

Ok let's reopen this then... Sorry I had been meaning to comment but forgot.

I get setFirstDayOfWeek, but please describe setMinimalDaysInFirstWeek to me.

@andrewplummer andrewplummer reopened this May 15, 2012
@skinnybrit51

setMinimalDaysInFirstWeek determines how many days need to be in the first week of any year to make it count as a week.

JAVA API docs it as - Sets what the minimal days required in the first week of the year are; For example, if the first week is defined as one that contains the first day of the first month of a year, call this method with value 1.

@andrewplummer
Owner

And what is the default for this? How does it manifest itself? Is it based on an ISO standard or...?

@skinnybrit51

Normally the default values are taken from a locale resource. This is how strongly typed languages work.

@tomByrer

FYI:: ISO8601 describes Monday as start of the week, and the first week in a year has the first Thursday.
https://en.wikipedia.org/wiki/ISO_8601#Week_dates

@andrewplummer
Owner

@mmaltby Yikes... that's where shit's gonna hit the fan :)

I'll be thinking about it though.

@andrewplummer
Owner

OK I've been a bit busy, but I want to take another look at this:

  1. Here's the problem. Native JS getDay returns 0-6, with 0 meaning "Sunday". Would a setFirstDayOfWeek function override this output? If so, I'm worried about overriding native JS methods (Sugar does not do this anywhere else with the small exception of not throwing errors where they would otherwise be thrown), if not, then you would have a discrepancy. The end user of Sugar should definitely not have to care which methods are native and which are Sugar.
  2. Am I correct in thinking that the entire issue with setMinimalDaysInFirstWeek is not at all related to the "weekdays" issue? I can't see how it would be. Also I don't really see the need for it either has ISO has a very straightforward definition of what counts as a week (the first Thursday), and I have made a number of revisions to make sure that this works right. Are there competing standards here?
@inossidabile

No-no-no! NO WAI! We should never override the default native methods! This is incredibly embarrassing and is a potential source of epic bugs.

@inossidabile

I mean if I had to choose between implementation of this issue or leaving the getDay alone I will die hard to leave the method untouched. Imagine how much fun you gonna have with external collisions. This is totally not an option.

@andrewplummer
Owner

I tend to agree, although perhaps not so strongly :) (but don't worry, strongly enough)

However if this method simply "doesn't apply" here, it seems like a major source of confusion. So what else are we talking about here? What else would resetting the beginning of the week gain, aside from Date.create("beginning of week") becoming monday instead? And how could this really be any better than simply Date.create().setDay(1)?

@andrewplummer
Owner

Or even Date.create('monday') for that matter?

@inossidabile

Ye, I agree. Looking from this angle it doesn't look like a good idea to me anymore. This should be implemented on another (way lower) level. As I told before I could find a use for this. However in a real life most of dates come from server-side or the date picker (which has such a feature). In the other cases explicit monday declaration feels ok.

@skinnybrit51

What about

Date.setFirstDayOfWeek(int)
Date.setMinimalDaysInFirstWeek(int)

The settings last for duration of sugar dates being loaded.

@andrewplummer
Owner

This still doesn't address the above issues.... I mean this is what we've been talking about from the beginning anyway, no?

@andrewplummer
Owner

Ok I think it's time to close this again. If you can figure out exactly what it is you want in Javascript terms ("well Java has it" is not enough) and the exact use case for it, feel free to comment. I'm always willing to listen and in this case probably will consider a different approach to the issue.

@moll
moll commented Aug 19, 2012

Seems I also got bitten by the differences of week start days.

I'm building a calendar and was using setWeekday(1) to jump to the current week's Monday. But, obviously, running that code on Sundays is wrong when you go by ISO 8601 a.k.a Europe and international business standards and consider Monday to be the beginning of your week. As JavaScript considers weeks to start on Sundays, it'll give you the "next week" in Europe's terms.

While, yeah, you could work around it by custom code, it severely limits usefulness of Sugar's helpers (like setWeekday), as you should never use them on code that runs for Europe.

Changing native Date API is definitely not a good idea, but taking differences or locales into account in helpers makes sense IMO. Otherwise thinking of methods like beginningOfWeek gets really complicated if you have to remember it gives you a different answer on Sundays.

@andrewplummer
Owner

This idea may have merit if locales can agree on a single day of the week to start on... however if there is any ambiguity in any of the locales, this "feature" will quickly become a disaster of having to second guess the locale. As it stands, it may not be perfect but there is much less surprise involved. Also when you throw in the concept of "ISO8601", this seems like less of a locale driven point, as it is part of your application logic. (if you're following ISO8601, then surely that wouldn't just apply to any single locale)?

Another point is that setWeekday is simply an alias for setDay. It shouldn't ever behave differently unless we're talking about overriding Javascript native functionality, which I think we all agreed is not good.

So again we come back to a potential split definition of what constitutes the "beginning". IF this constitutes a change that has major benefit, it could be considered, but the benefit would have to be pretty major, as anyone else not making these assumptions about this potentially "quirky" behavior of locales would easily be just as "burned" by the opposite effect.

For my part, I believe that locales should not dictate differences in core functionality. They are instead only concerned about parsing and outputting language.

Let's put this another way... under the current system, you could have a fully localized site that you could depend on to a certain degree to have faithful representations of the date in other languages even if you don't yourself speak those languages. You could manipulate the dates and be sure that "Sunday" is still "Sunday", even if the semantics of methods like beginningOfWeek are not technically correct for that locale. If we were to make this change that degree of certainty would be undermined because you would essentially be required to have knowledge specific to that locale to be able to manipulate a date to any degree of certainty.

This is not to mention that locales are not themselves something "attached" to a date in any meaningful sense, but are simply an argument passed to the method or set globally. Are all dates to be manipulated differently simply because the global locale is set to something else?

The more I think about it the less this seems like a good idea to me.

@moll
moll commented Aug 19, 2012

You seem to have thought about locales more than I have. Though, when it comes to start-of-week in end-user UI-s, that is something I believe should be (and I'm building into my calendar app):

  1. customer-changeable and
  2. detected based on their signup region.

Personally, I've grown up with Monday on the leftmost calendar column. I'm guessing Americas expect Sunday there. While it might affect business logic (I can't think of an example, though), I also consider it a presentation issue. You and I should both be able to collaborate, regardless where we consider our weeks to start and end.

So, all this cultural talk leaves functions with relative names, like beginningOfWeek, in a limbo. It's kind of like having a method getMorning that returns UTC 8am next to methods that do have local and UTC counterparts. :)

@moll
moll commented Aug 19, 2012

One option that sprung into my mind would be to have such "l10n"-able methods available in a form that takes a globally set start of week into account.

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