I have a few places in the code where I need to use the TimeZone. I can get the timezone name using DateTime::TimeZone. Is it reasonable to put the timezone name in a constant? Or should it be in a variable?
If the value can change, use a variable, of it is guaranteed to stay the same, use a constant.
For a timezone, the chance it will change is not big, but it is also not 0. The user can change the timezone and it would be nice if the program behaves accordingly.
I vote for variable. You could end up with different users in different timezones working with your application, even if you doubt that could ever happen. It happened to me a couple of years ago.
Look at where the timezone is coming from. Is it the timezone of a city? Make it constant. Is it the timezone of the user? Make it variable - we users travel all the time, and we reset the timezone on our laptops so that Outlook scheduling will work correctly at the new location.
Related
I've lost track of how many questions & responses I've read while trying to find an answer on this. The ones that sound like they're related often aren't, or else the users are just accused of being confused. (As an example, the first answer here just tells the person asking the question that they don't really mean to be asking what they're asking. Then there's this one. The most upvoted answer here says it's just impossible. Etc., etc., etc.)
I need to be able to take a time--say 9:00 AM--and work with it as 9:00 AM regardless of which timezone my user is in. If a user pulls up this time in a US/Eastern timezone, they should see this value as 9:00 AM. If a user pulls up this time in a US/Pacific timezone, they should see this value as 9:00 AM. I recognize that this is not actually the same moment in time, and I don't need it to be.
To illustrate, let's call the timezone-immune timestamp I'm talking about timezoneImmuneTimestamp, and say that its value should always be 9:00 AM.
Say I'm executing someMomentInUsEasternTimezone.diff(timezoneImmuneTimestamp, 'minutes'), where someMomentInUsEasternTimezone is equal to 10:00AM (EST). The answer I need is 60 minutes.
Now let's add another Moment, someMomentInUsPacificTimezone and say its value is 11:00AM (PST). When I execute someMomentInUsWesternTimezone.diff(timezoneImmuneTimestamp, 'minutes'), the answer I need is 120 minutes.
Has anyone else had this particular problem, and more importantly, solved it?
It sounds like you want to work with only the "wall time" of each moment object. To do that, first create a clone of each moment and set their offsets to zero, as if they were UTC. When doing so, pass true to keep the wall time instead of the same point in actual universal time.
This is described in the docs for the utcOffset function:
The utcOffset function has an optional second parameter which accepts
a boolean value indicating whether to keep the existing time of day.
Passing false (the default) will keep the same instant in Universal Time, but the local time will change.
Passing true will keep the same local time, but at the expense of choosing a different point in Universal Time.
Thus, to get the difference in minutes between momentA and momentB with respect only to wall time:
momentA.clone().utcOffset(0, true).diff(momentB.clone().utcOffset(0, true), 'minutes')
Though missing from the docs, the same argument can be passed to the utc function. So if you prefer, you can shorten it to:
momentA.clone().utc(true).diff(momentB.clone().utc(true), 'minutes')
(Cloning helps the rest of your code by not mutating the original moment objects.)
Also - The Moment team highly recommends only using Moment in legacy/existing code. If you are writing a new application, please try Luxon instead. In Luxon, the setZone function has a keepLocalTime option that does the same thing as I showed in Moment.
When I write a Timestamp on Firestore it shows 6.00PM on database though I have not defined any time in the Date object.
My Approach to get Timestamp from date :
let reservationDate = new Date(year,month,dayOfMonth);
let bookedRoomData = {
....
...
reservationDate: admin.firestore.Timestamp.fromDate(reservationDate),
...
};
What is the reason behind showing 6.00PM instead of 12.00AM ?
What should be done to fix this?
Screenshot of database is given bellow -
Since you tagged this google-cloud-functions, I'm assuming that your code is running in Cloud Functions.
When you create a new Date object on any machine, it uses the local machine's sense of timezone. So you're making a date at midnight in whatever timezone has been assigned to your Cloud Functions instance. It's not the timezone where you're computer's clock is set.
When you see a timestamp in the console, it's always going to appear on your computer's clock's configured timezone. So, your computer is 6 hours behind whatever is being used by Cloud Functions.
If you want a specific time, you should make sure your Date is configured that way. Consider using a library such as momentjs to create dates according to timezones of your interest. Bear in mind that Timestamp objects do not encode a timezone. They just render in the console according to your local timezone.
I am facing an issue with setting time on page properties on cq:Page. The time being set into the JCR is getting converted to the timezone that is set in author’s machine. For example: time being set when author is in India is saved as +5:30 while in NY it is being set with -4:00 offset. Is there any way this can be fixed ?
Thanks !
I don't think you want to change this, unless I misunderstood the issue. Time is linear, so at any given point in time, there are as many possible ways to express the time as there are valid time zones. Anyone who views that page information through the application (not directly viewing the JCR) should see that timestamp converted to their local system time.
I'm using GWT on the client (browser) and Joda Time on the server. I'd like to perform some DB lookups bounded by the day (i.e. 00:00:00 until 23:59:59) that a request comes in, with the time boundaries based on the user's (i.e. browser) timezone.
So I have the GWT code do a new java.util.Date() to get the time of the request, and send that to the server. Then I use Joda Time like so:
new DateTime(clientDate).toDateMidnight().toDateTime()
The trouble of course is that toDateMidnight(), in the absence of a specified TimeZone, will use the system's (i.e. the server's) TimeZone. I've been trying to find a simple way to pass the TimeZone from the browser to the server without much luck. In GWT I can get the GMT offset with:
DateTimeFormat.getFormat("Z").fmt(new Date())
which results in something like "-0400". But Joda Time's DateTimeZone.forID() wants strings formatted like "America/New_York", or an integer argument of hours and minutes. Of course I can parse "-0400" into -4 hours and 0 minutes, but I'm wondering if there is not a more straightforward way of doing this.
You could use java.util.Date's getTimezoneOffset() method. It's deprecated, but that's pretty usual for Date handling in GWT currently.
And AFAIR, you can specify something similar to "UTC+4" in Joda time.
Update: I looked it up, and it's "+04:00". Or use DateTimeZone.forOffsetHours() or even forOffsetMillis().
Gwittir (http://www.gwtsite.com) is a library for GWT that includes many cool utilities, like databinding, animation, reflection, and more. However, there are some other interesting goodies as well like the new Joda Time integration. If you have ever been frustrated by GWT’s lack of java.util.Calendar support, you’ll love this, as it makes it easy to do date manipulations in your applications.
otherwise, there are other ways to get timezone offset with + & -.
import java.util.TimeZone;
use: TimeZone.getDefault().getRawOffset()
this function will return the offset time in millisecond about your phone seeting. For Example, GMT-04:00 is equals to (-4)*60*60*1000 = -14400000.
After some operations to get the number which you want.
I have a similar but slightly different problem I think.
I actually need to store the clients timezone on the server, so that I can send out messages about dates stored in their calendar.
The dates are stored in UTC time in google app engine and of course I can store the current Timezone offset when creating the appointment. The problem comes when for instance I want to send out a summary email with a list of upcoming appointments in it. These appointments need to be offset with the correct Timezone adjustments for the client (Im happy to assume that they are still in the same timezone as when they created the appointment).
The real problem comes with Daylight Savings adjustments, so for instance I might have appointments stored for Saturday 30th October 2010 at 1pm (BST[GMT+60]) and Monday 1st November 2010 at 1pm (GMT).
So as you can imagine, I cant just use the current timezone offset (BST) as that would mean that the appointment on Monday 1st November would be listed as 2pm rather than 1pm (GMT+60)
It occurs to me that the best way to deal with this is just to store the timezone offset with each appointment individually, but I feel it would be much better to be able to determine the original timezone correctly in the first place, then just let java do the correct adjustments.
I've noticed that on some devices the NSTimeZone's name method for a particular timezone can return different values. When testing the Brisbane time zone, my device returns #"Australia/Brisbane" whereas another user's device returns "Etc/GMT-10". Both iPhone's are running 3.1.2.
The Date and Time Programming Guide for Cocoa states that:
timeZoneWithName: The name passed to this method may be in any of the
formats understood by the system, for
example EST, Etc/GMT-2,
America/Argentina/Buenos_Aires,
Europe/Monaco, or US/Pacific, as shown
in the following code fragment.
I'd just like to know what could determine which value is used? The device? The language?
I've discovered what the reason for this was.
When manually setting the timezone from Apple's build-in list, the correct and exact timezone name is returned. However, some mobile carriers provide the current time zone offset over the air, and if this is the case, Apple provide an "Automatic" setting which allows the iPhone to change time zone automatically when they move across into another time zone.
The problem is that while the current GMT offset is provided, there's no way to tell what latitude the user is at. Obviously, there may be for example, several cities in Australia with the a time zone of GMT -10. Therefore, no specific time zone name is available, only that the phone is currently GMT -10.
I've never scene what you describe. In my experience it returns the name you created it with.
In any case, if you're using the name for UI display, you should call [NSTimeZone localizedName:locale:] to force the name style you want.