0

I'm trying to dynamically get the user timezone and apply it to the dateTime values in my payload.

I'm currently using this function in dataweave:

var dateTimeZone = now() as TimeZone

fun formatDate(dtValue :String, dateTimeZone: TimeZone) : DateTime =  
  dtValue as DateTime {format: "yyyy-MM-dd'T'HH:mm:ss.SSSZ"} as DateTime {"format" : "dd/MM/yyyy HH:mm", timezone: dateTimeZone}

When I run this code locally it works as expected. When I deploy my API to CloudHub I found out it uses UTC (which I suppose is the server's timezone)

I however need to get the user timezone wherever they are, so if the user is in California for example I need it to format it to "PST".

Is there a workaround to this problem that I can implement in code without adding query parameters or changing anything but this function?

Zyoumir
  • 33
  • 6
  • 2
    Well time zone information has to come from *somewhere*. All you've got is the request... so which aspect of the existing request do you expect to get the time zone from? You could *potentially* reverse geocode the client IP address, but that feels unreliable for various reasons. I would personally put it as a query parameter or make it part of the actual request body: it's part of the information required for your API to work, so why shouldn't it be somewhere explicit in the request? – Jon Skeet Jun 01 '23 at 07:58
  • 1
    (As an aside, I would expect the formatting to use America/Los_Angeles, *not* PST - because PST is always *standard* time, whereas California uses both PST and PDT. I'd basically recommend avoiding abbreviations as far as possible... the *only* place I'd *consider* using them is in the output itself.) – Jon Skeet Jun 01 '23 at 07:58
  • 2
    As an alternative, if you've got the idea of "a user" stored somewhere you could make it part of the user's settings. That's not quite the same as "wherever they are" of course - I live in the UK, so I'd expect my settings to have Europe/London, but that isn't always where I am. You should think about what users really want to see when they're travelling - we can't really advise you on that as we don't know anything about your app. – Jon Skeet Jun 01 '23 at 08:00
  • It's client requirements that block me from qdding it to query parameters, and I agree that reverse geocoding the IP adress is too much of a hassle. I thought there might be another way to do it in dataweave – Zyoumir Jun 01 '23 at 08:23
  • Forget what a particular platform makes easy for you. If the information isn't fundamentally available, how can a platform help? If you wanted to know the user's birthday for example, would you expect that to be available without the user ever specifying it? It's impossible. The same is true for a time zone. Note that I didn't say that reverse geocoding the IP address is "too much of a hassle" - I said it's *unreliable* (e.g. for VPN reasons). But that's the only information about where a user comes from which is available *at all* unless you've got a signed-in user with a location stored. – Jon Skeet Jun 01 '23 at 09:15
  • What exactly do you need the datetime for in your case? I mean for storing it or for displaying it on a UI? – Harshank Bansal Jun 01 '23 at 11:47
  • I need it to update the timezones accordingly for each user around the world, we ended up using the User table on salesforce, querying to it and it returns a field containing the timezone. So I accepted aled'd response because technically it is the solution. – Zyoumir Jun 21 '23 at 15:23

1 Answers1

1

Timezone of the client of an API is not something your API implementation knows, whatever the technology. You need to receive it from the request, as a query parameter or from a the body of the request.

aled
  • 21,330
  • 3
  • 27
  • 34
  • we ended up using the "User" Object in Salesforce through an http request inside the application, and looked for the timesidkey column which contained the timezone. So i'll accept this as the answer to this question. – Zyoumir Jun 06 '23 at 13:54