I have a simple system, which on node creation form, allows user to select start and end dates along with hours and minutes:
The problem is that the date gets messed up somewhere in the middle, or I don't know how to convert it.
In the database, two values gets saved as follows:
start: "2019-08-01T14:00:00.000Z"
end: "2019-08-01T16:00:00.000Z"
Seems correct, as in the datepicker I chose 2pm and 4pm. Then, using momentjs and react-big-calendar, I try to put that event into calendar. It seems that it puts +3 hours every time. I assume, it is because it saves it in UTC format, and I live in Eastern Europe, which is +3 hours from UTC.
What is strange, is that I already get back time converted to my own when I make a request to the database:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
Could someone help me out? I would expect to have the same hours returned and displayed, as I save them, meaning if I select 2pm, it should be 2pm. I think the solution here would be to ignore timezones, and always display everything in UTC? But how to do that? I have access to momentjs if that helps. I tried something like this:
moment.utc(event.start);
But it still returns the same value, which is:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
When you setup React-Big-Calendar, you define a localizer. By default, the calendar will display in the local timezone of the browser the user is using. Any and all dates given to the calendar will be converted to that local timezone. If your dates, coming from the db, use an offset of +5, but you're sitting in +3, it will automatically convert those times to display +3 (part of the beauty of UTC).
This is where it can get tricky. Say I want to get all values from my db between Sep 19th and Sep 21st. I have to remember those offsets when requesting data from the system. I could use moment and say moment('2019-09-19').startOf('day'), and it would give me 2019-09-19T00:00:00Z, but this isn't exactly correct for me, as I'm at an offset of -5, which means I actually needed 2019-09-18T19:00:00Z to get the start of my day. The same holds true for my end datetime, where I would say moment('2019-09-21').endOf('day') and it would give me 2019-09-21T23:59:59Z, when I would need 2019-09-21T18:59:59Z.
Now, I'm not positive of this (you'll have to do some testing), but if you use moment-timezone instead of moment it may handle all of this for you. You'll have to play around to know for sure.
FINAL EDIT: I worked out timezone handling with moment-timezone as my localizer. I put the entire thing in a GitHub project, as well as creating a CodeSandbox where people can play with it.
TRULY FINAL EDIT: The (0.36.0) latest version of RBC has full timezone support now, when using either the momentLocalizer or the new luxonLocalizer. Doc site isn't up to date yet, but if you run the 'examples' locally you'll find all the info.
Related
I have a date field at front end. And I am saving it from a time zone say 19/04/2018 and I am on +8. When I load it on local datetime.ToLocalTime() works perfectly in +8 offset and it will show 19/04/2018 but a person sitting in +7 would get in 18/04/2018 23:00 and hence it will show 18/04/2018. How to handle this case.
In general: you should not convert date only to UTC, so you should keep it as local date.
But it really depend on the use of data.
If you are using for some synchronization (all invoices until a fix point), a time with timezone is good, but in such case, also hours and minutes should be included.
If you care about the date written in an invoice, you may not transform date to UTC (so keep local date). If you aggregate invoices, you may wait until the day is passed on all timezone (and people filled all invoices into the system).
When people are looking into the data, what they expect? (case #1 or case #2). Then evaluate what kind of data you need. In the first case, you should add also (at minimum) the hours and minute (timezones never have seconds).
In general, if you have only a date, you are mostly on second case.
I have the following link for a user to create a Google calendar event
https://calendar.google.com/calendar/render?action=TEMPLATE&text=Your+Event+Name&dates=20140127T224000Z/20140320T221500Z&ctz=America/Los_Angeles&details=For+details,+link+here:+http://www.example.com&location=Waldorf+Astoria,+301+Park+Ave+,+New+York,+NY+10022&sf=true&output=xml#eventpage_6
I originally found this out using the example from Link to add to google calendar
The issue I am having is to do with the time part of the URL which is
&dates=20140127T224000Z/20140320T221500Z
to break this down the format for this in which Google uses to determine the start/end date and time is
Ymd\\THi00\\Z
So you understand Google uses GMT as a standard time in the url and converts it correctly according to the users settings in their Google account. For instance (GMT-07:00) Pacific Time
So let's take just the start time of this URL which is
224000 which is Hi00 or Hour:Minutes:Seconds
In my Google calendar, my timezone settings are set to Pacific which is -7. Converting 224000 GMT to -7 Pacific you get 154000 which should be 3:40 PM
Problem is when you click the link, (if you are pacific) it is showing me the start time as 2:40 PM
What's even weirder is the end time which is 221500 shows as 3:15 PM. The end time hour is still the same as the start time but shows 1 hour ahead. I get that Google is probably assuming that I mean 1 hour ahead and makes that change for me, OR by default Google probably adds 1 hour more from the start time automatically.
I am not sure if I am understanding the format Google uses GMT in the URL or there is an issue with my coding and how I am representing that. Anyone have any info on this?
You may want to check this page wherein it discussed how Google Calendar uses time zones. As mentioned,
When you create an event, you'll see it in your local time zone. It will also show up in the local time zones for anyone you invite, even if they're in a different time zone.
And, on Daylight savings time:
Google Calendar uses Coordinated Universal Time (UTC) to help avoid issues with daylight savings time.
When events are created, they're converted into UTC, but you'll always see them in your local time.
If an area switches their time zone, events created before we knew about the change might be in the wrong time zone.
With this, you may want to try the given workarounds in this thread and see if it will help you.
I have a simple mobile app that schedules future events between people at a specified location. These events may be physical or virtual, so the time specified for the event may or may not be in the same timezone as the 'location' of the event. For example, a physical meeting may be scheduled for two people in London at local time 10am on a specified date. Alternatively, a Skype call may be scheduled for two people in different timezones at 4pm (in one person's timezone) on a specified date though the 'location' of the event is simply 'office' which means two different places in different timezones.
I wonder the following design is going to work for this application:
On the client, it asks user to input the local date and time and specify the timezone local to the event.
On the server, it converts the local date and time with the provided timezone into UTC timestamp, and store this timestamp only.
When a client retrieves these details, it receives the UTC timestamp only and converts it into local time in the same timezone as the client's current timezone. The client's current timezone is determined by the current system timezone setting, which I think is automatically adjusted based on the client's location (of course, assuming the client is connected to a mobile network).
My main motivations for this design are:
UTC is an absolute and universal time standard, and you can convert to/from it from/to any timezone.
Users only care about the local date and time in the timezone they are currently in.
Is this a feasible design? If not, what specific scenarios would break the application or severely affect user experience? Critiques welcome.
For a single event, knowing the UTC instant on which it occurs is usually enough, so long as you have the right UTC instant (see later).
For repeated events, you need to know the time zone in which it repeats... not just the UTC offset, but the actual time zone. For example, if I schedule a weekly meeting at 5pm in Europe/London with colleagues in America/Los_Angeles, then for most of the year it will occur at 9am for them... but for a couple of weeks in the year it will occur at 8am and for a couple of weeks in the year it will occur at 10am, due to differences in when DST is observed.
Even for a single event, you might want to consider what happens if time zone rules change. Suppose I schedule a meeting for 4pm on March 20th 2018, in the Europe/London time zone. Currently that will occur with a UTC offset of 0... but suppose between now and the meeting, the time zone rules change to bring British Summer Time in one hour earlier. If I've written it in my diary as 4pm, I probably don't want the software to think that it's actually at 5pm because that's the UTC instant we originally predicted.
We don't know your exact application requirements, but the above situations at least provide an argument for potentially storing the local time and time zone instead of the UTC instant... but you'll also need to work out what to do if the local time ends up being skipped or being ambiguous due to DST changes. (When the clocks fall back, some local times occur twice. When the clocks skip forward, some local times are skipped. A time that was unambiguous may become invalid or ambiguous if the rules change between the original planning time and the actual event. You should probably account for this in your design.)
To keep it simple, my answers are:
Timezone info is redundant if you want to define a single moment. A
UTC/Unix timestamp completely defines a moment.
Your design seems feasible but on point 2: i would convert to the UTC/Unix timestamp on the client-side and already give this timestamp
in its final form to the server. Reason: the client-side already has the info necessary to convert (see this time-keeping
client-server-db
architecture
example - it works based exactly on the principles you describe).
One possible problem (as described by Jon Skeet in his answer) are recurring events, but this should be reflected in the way you model
time. The difference between recurring events and fixed events is
that the latter completely define a moment (like a UTC/Unix
timestamp) while the first are only a 'function' which can be applied
to the current time to get the next trigger time of the recurring
event. But this might entirely be a different problem than what
you ask - in any case, somehow distinguishing between recurring
events (if you need them) and fixed events in your model is a good
idea.
One decision to make is: PULL or PUSH? Or both? Do you want the server to be able to send emails for example, when an event comes to
pass? Or do you want client-side alerts only when your client-side
app is running? The answers to these questions will help you come
towards a design suitable for you.
I Need to get the current Eastern time zone.
I am using asp classic. I tried alot but I did not got the solution.
Any one can help me.
I am using
Now()
to get the current value in vb classic but i need current time in Eastern time zone.
I disagree that converting to UTC time is the way to go, precisely because then you get to deal with the headaches of daylight savings time. Instead, figure out what time zone the server is set to, figure out what the offset is from that to Eastern time, and then instead of just Now, use DateAdd('h',3,Now). (Naturally, replace 3 with the correct number if the server is not on the west coast.)
Alex K has the right answer, which he put in the form of a comment. Here it is in the form of an answer:
Get UTC time -> stackoverflow.com/a/11441116/246342 Add the offset (remembering some places will use daylight savings in the summer)
For my apps I try to store all times as UTC to avoid this problem. For some date/time calcs I can get by with the local time zone of the server, such as when I just need to know elapsed time. So then I'm just careful to make sure the server time zone is what I expect in case I ever need to display it. For example, our marketing dept doesn't think having our special offers expire at "midnight UTC" is very user-friendly, so we just say "midnight Central Time" and let people convert in their heads to their local time. Internally I can compare Now to the expiration date of the offer and it works fine.
We have a really strange problem in xpages regarding dates, the Notesdocument we have contain a date field and the value is only a date, there is no time portion.
In the xpage I have specified to display the date as a date/time value. the date display correctly on the webpage but we are now getting reports from users who login at night (around midnight) and see the date as adjusted by one day. if the same people login at daytime the date is correct so this only seem to happend around midnight
I have tried to change my clock on my client to around midnight but that does not reproduce it so I assume this is a server issue.
The domino server have correct date/time and we are using the latest version of Domino
any ideas?
we encountered the same problem recently and, I believe, found a very nice solution.
system treats the pure date as a date in UTC time zone. Date value is automatically converted into server's time zone. So the question is how to prevent conversion?
this code prevents conversion:
<xp:this.converter>
<xp:convertDateTime
type="date"
ignoreUserTimeZone="true"
dateStyle="long"
timeZone="UTC">
</xp:convertDateTime>
</xp:this.converter>
pay attention at "timeZone" attribute.
The issue is related to not having the TimeZone specified in the date / time field. We ran into this just yesterday. If you don't have the TZ specified, it seems to assume UTC and will adjust accordingly. Include the time zone and your field will stop adjusting erroneously.
Perhaps it has to do with this ?
http://www-304.ibm.com/support/docview.wss?uid=swg21508734
I've seen some reports about XPages Dates and TimeZone Issues
I suspect your Domino version was 8.5.3, because there were 2 APAR, LO72278 and LO67745, on similar problems against 8.5.3. Fixpack 3 addresses them.
The root cause is that Lotus Notes allows you to save a "Date" with no time or zone and the Notes server has a default Time Zone setting to interpret these incomplete things called dates. XPages doesn't play by the same rules, and its master Java wants to know what zone you're using, and looks to the system for some clue, and generally will use midnight within some TZ to refer to a "Date". There is a whole region on Stack Overflow on the "how to store/represent a date" topic - [datetime] - since languages and DBMS each have their own approach.
Nice legacy Notes focused article about it.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/05022009100728PMAGU5MB.htm
XPages article about it
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/XPagesTimeZones.htm
Too bad they are not totally on the same page, I assume each release gets closer.