Closed majioa closed 7 years ago
What are those "old calendars" and why do you need an offset?
For example old greek calendar, old (and modern godservice) church calendar.
Also reset_time() is used to unify dates and allow their comparison later, so I expect setting an offset to break the rest of the code.
What do you mean "unify dates" ? The reset_time
method was not changed, just today date.
For example old greek calendar, old (and modern godservice) church calendar.
Understood, and why to you need to change the time?
What do you mean "unify dates" ?
I mean that time reset is done in order to be able to compare dates easily later. Each date internally is consistently set to 0 hours, 0 minutes, 0 seconds and 0 milliseconds, so that date1.valueOf() === date2.valueOf()
for the same date, otherwise comparison becomes tricky.
Understood, and why to you need to change the time?
Just use the border of the day at 16:00
I mean that time reset is done in order to be able to compare dates easily later.
That is good, think any comparisons will be done perfectly because the today offset is used to calculate the proper current date before resetting the time. For example with today_offset
equal to 8h, the today at 16:00 becomes tomorrow before call to reset...
, that is well expected.
So from what I understand you want to show current days on the calendar using ancient calendar that has some offset relatively to the current date and time on host system browser runs at (Date
object always uses system date, time and timezone). However, I don't think this is this simple, namely to add an offset, because an offset might be variable and some calendars might not even have the same number of days as current calendar.
If this is to be implemented I see 2 different approaches:
render
callback to also support today
property (see this)Date
object, so that it can be used instead of built-in browser implementation and implementation might do all of the tricky things necessary for any custom calendarI think in your case with custom offset (even variable one) we can approach it with "easier way". I'd be happy to accept an updated PR where you implement today
property similarly to selected
as I've linked above. This will allow you to decide which day is "today" in render
callback manually and thus override default behavior.
You can git push --force
commits into the same branch to avoid creating new PR.
easier way is to extend render callback to also support today property (see this)
I've tried similar way but got just workaround code....
difficult and more complete solution is to allow specifying custom Date object, ... happy to accept an updated PR where you implement today property similarly to selected
I've implemented the today
property instead of the today_offset
but it seems it requires the field value recalculation on the day change. So for me more explicit way is that I've implemented with today_offset
.
Rendering is called each time date selection is changed, so it shouldn't be very explicit. Were can I look at what you have right now?
@nazar-pc yes, and in that way the calendar just resetted the today date to improper state
http://dneslov.org that is the site with the patched calendary. The day border is at 16:00
I said that with extension I've suggested you control what is today
, so there will be no "improper state" if you code render
callback correctly.
What are those "old calendars" and why do you need an offset? Also
reset_time()
is used to unify dates and allow their comparison later, so I expect setting an offset to break the rest of the code.