0

Development is in one place and deployment is in another location for a web -application. During development, I used my own location timezone to fetch and persist the date values in the DB(Oracle).

But after deployment, to another location time zone are totally different and date seems to cause a major issue in the course of testing.

This is a simple application wherein I use Java for Backend and Angular 5 for front-end. Data persist is done with Oracle DB.

I am not sure how to handle this time zone difference. Is there any specific way to handle this difference? Any inputs are most welcome.

[EDIT]: So, the requirement is simple - wherever the user logs in the application, he must be able to view the Date and time as per his timezone. Even if the user Creates/Modifies an item, he must be able to view the time as per his timezone.

For Ex: If I am posting a post/status, then the time at my end must show the timezone for my location. Similarly, If I see the same post/status in another geography, then I must see the time respective to that time zone.

Ashfaque Rifaye
  • 1,041
  • 3
  • 13
  • 22
  • 1
    You need to define your requirements for what the end user experience should be... – Affe Mar 05 '19 at 16:20

2 Answers2

2

Anything with timezones is not fun at all. My suggestion would be to make sure you're converting your dates to UTC on the server and persisting them that way, then converting them back on the client.

I don't know how you're passing dates to the server, but something like

Determine TimeZone from a JSON String? could be useful.

For a better discussion, see:

Should the Server or the Client handle timezone when sending/receiving dates?

How to properly work with Timezone?

Good luck!

Edit:

As noted by Jon Skeet below, this is not necessarily a good idea. A conversion to UTC without a timezone is "lossy". If timezones change (and they do from time to time), then your UTC timestamp no longer represents what it was originally intended to.

Take a look at this page and make some decisions about your datatypes (TIMESTAMP WITH TIME ZONE will preserve the timezone entered by the user, if this is required).

https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm

Just about everything you do with dates/times is going to be full of caveats, and this question doesn't give a lot of information about what the application's requirements are for storing/displaying date and time information.

Kris
  • 566
  • 3
  • 12
  • 2
    See my comments on Waxhaw's answer for an example of why "store everything in UTC" isn't a universally good idea. – Jon Skeet Mar 05 '19 at 19:46
  • @Kris I have updated the Requirements. I do agree that there will be a timezone changes and I also do agree that the conversions will be lossy at times without a Timezone. So is there any proper solutions as far now for the requirements mentioned? – Ashfaque Rifaye Mar 06 '19 at 06:35
1

I'm guessing that you are using Java Date objects correct? If you are using Java 8 you should consider these two:

OffsetDateTime
A date-time with an offset from UTC/Greenwich in the ISO-8601 calendar system, such as 2007-12-03T10:15:30+01:00.

OffsetTime
A time with an offset from UTC/Greenwich in the ISO-8601 calendar system, such as 10:15:30+01:00.

https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

If you are saving it to Oracle and all you need is a DATE then I would suggest you save it as a String and format it using "YYYY-MM-DD".

By default the Java JVM ALWAYS adds the local JVM TZ (TimeZone) values to any date object.

So let's look at a business case. If you have customers in 4 different regions of the USA and you need to report on date/time events in their LOCAL TIME then you MUST save to the DB in GMT time. By default the local TZ will adjust this accordingly. Oracle's built in Date/Time objects do this by default as does EVERY major Operating System. So create a DIR, notice the current time and then go into your regional settings for your OS and change your timezone. The DIR creation date will automatically be translated.

At it's simplest form this is a perfect case of Model-View-Controller. Where the TZ change is the Controller. The Model is the GMT value and the View is translated to the current user's TimeZone.

I hope this helps you. PLEASE use GMT and don't over think it. Saving to a DB NOT using GMT is asking for trouble in my humble opinion.

Cheers

Waxhaw
  • 599
  • 5
  • 9
  • 1
    "PLEASE use GMT and don't over think it." Well, unless you're actually *trying* to accurately represent a local date/time chosen by a user. Suppose you take a time of "8am on December 1st 2020 in Paris". If you convert that to UTC *now*, then it's entirely possible that by the time we get to December 1st 2020, the stored value would be 9am in Paris, due to legislation to abandon daylight savings in Europe. It's generally a good idea to save timestamps in UTC (or with an offset) but when the user has provided information, *save that information*. And *do* think about date/time - it's nontrivial – Jon Skeet Mar 05 '19 at 16:33
  • The local JVM TZ settings take all of this into account and it basically gets it from the native OS. Use GMT and let the device who displays it show it correctly. Doing anything else is the path to pain and suffering. My 2 cents. – Waxhaw Mar 05 '19 at 18:44
  • "The local JVM TZ settings take all of this into account and it basically gets it from the native OS." But the OS can't time-travel to know what legislation is going to pass in France between now and 2020. You simply *can't* predict which instant in time will be "8am on December 1st 2020 in Paris" at the moment. "Doing anything else is the path to pain and suffering." Well, it requires *thought* rather than blindly following advice. And it may require more implementation time, too. But I'd rather have code that gives the right results in the end. – Jon Skeet Mar 05 '19 at 18:52
  • So Jon are you going to maintain a DB of TZ settings based on every country that changes how they handle it? Good luck with that. I worked in telecom for a long time and they use GMT because it WORKS. Save to GMT and then figure out how to present it based on the local user's TZ. – Waxhaw Mar 06 '19 at 17:01
  • "So Jon are you going to maintain a DB of TZ settings based on every country that changes how they handle it?" No, [IANA does that already](https://www.iana.org/time-zones). I publish releases to [Noda Time](https://nodatime.org) when there are changes. "It works" depends very much on the context. If the input is a future local time, and at that point in the future a *different* value is reported, I don't call that working. That may not have been something you needed to do, or it may be that it wasn't sufficiently broken to attract attention - but this is **not** a universally good approach. – Jon Skeet Mar 06 '19 at 17:08