If your machine is on the local time you want you can use the following
@TimeZoneSet(@Value(date),local,auto)
This will give you the time with offset, which you can then apply
Thanks for your answer ebygomm.
The data is not processed on the date it was created. Therefore, i have a datetime to convert that could be from 6 months ago or further… Therefore, I can not rely on the local time of my computer (I edited the question).
Thanks for your answer ebygomm.
The data is not processed on the date it was created. Therefore, i have a datetime to convert that could be from 6 months ago or further… Therefore, I can not rely on the local time of my computer (I edited the question).
The local does not relate to current time, but the time setting of your machine.
The formula should return the following if your machine is set to Paris time
e.g. if the attribute date has a value of 20200429120000 (2020-04-29 12:00:00), this formula will return
20200429120000+02:00 (plus 2 as during summertime
if the attribute date has a value of 202003428120000 (2020-03-28 12:00:00), it will return
20200328120000+01:00 (plus 1 as before daylight savings started)
Hi. It's pretty straightforward. This article may be of use: https://community.safe.com/s/article/converting-time-and-date-fields-to-local-timezones
Basically there isn't a transformer, but you use the TimeZoneSet function.
So in an attributeManager you create a new attribute (called zoned for example) with the function:
@TimeZoneSet(@Value(OriginalDateTime),utc)
That creates a new attribute with the UTC timezone attached (if the timezone is already attached, you could leave out that step)
Then a second new attribute (called local for example) with the function:
@TimeZoneSet(@Value(zoned),local)
That creates a new attribute with the local time, such as this:
There is one thing to consider: the "local" part of the second function, means use the local timezone of the computer being used. If you were using an Amazon AWS machine - for example - then its local timezone might be different. If you were worried about that, you could replace "local" with your required time zone (eg +01:00).
However... if you did hard-code the offset, it might be wrong, because sometimes it will be +1 (standard time) and other times +2 (daylight savings). Using "local" might solve that problem. But I'm going to check with our developers, because I'm not sure if that's true.
So I will find out and get back to you. But in the meantime the above functions and the tutorial I pointed to will give you a good starting point.
As far as I know,
Hi. It's pretty straightforward. This article may be of use: https://community.safe.com/s/article/converting-time-and-date-fields-to-local-timezones
Basically there isn't a transformer, but you use the TimeZoneSet function.
So in an attributeManager you create a new attribute (called zoned for example) with the function:
@TimeZoneSet(@Value(OriginalDateTime),utc)
That creates a new attribute with the UTC timezone attached (if the timezone is already attached, you could leave out that step)
Then a second new attribute (called local for example) with the function:
@TimeZoneSet(@Value(zoned),local)
That creates a new attribute with the local time, such as this:
There is one thing to consider: the "local" part of the second function, means use the local timezone of the computer being used. If you were using an Amazon AWS machine - for example - then its local timezone might be different. If you were worried about that, you could replace "local" with your required time zone (eg +01:00).
However... if you did hard-code the offset, it might be wrong, because sometimes it will be +1 (standard time) and other times +2 (daylight savings). Using "local" might solve that problem. But I'm going to check with our developers, because I'm not sure if that's true.
So I will find out and get back to you. But in the meantime the above functions and the tutorial I pointed to will give you a good starting point.
As far as I know,
Local will allow for daylight savings, hardcoding it will not
Local will allow for daylight savings, hardcoding it will not
I think you're right. But I asked the dev team to confirm - and to let me know how far back that information goes. Perhaps it's not an issue here, but if I gave it a date in 1978 for example, would it know whether DST applied for not?!
Local will allow for daylight savings, hardcoding it will not
Yes, i have no idea how it works or how far back it is accurate!
I know i checked the past 5 years by converting every date for the past 5 years and checking that the dates match the daylight savings changes previously
The local does not relate to current time, but the time setting of your machine.
The formula should return the following if your machine is set to Paris time
e.g. if the attribute date has a value of 20200429120000 (2020-04-29 12:00:00), this formula will return
20200429120000+02:00 (plus 2 as during summertime
if the attribute date has a value of 202003428120000 (2020-03-28 12:00:00), it will return
20200328120000+01:00 (plus 1 as before daylight savings started)
Alright, I managed to make it work !
I first convert my datetime "29-04-2020 12:00:00" to "20200429120000" (with substrings in AttributeManager). Next I apply TimeZoneSet to it. Then I apply TimeZoneGet to its result, to retrieve the "+01" or "+02" and finally I add this time difference to my time.
Thank you very much, you were a great help !
Local will allow for daylight savings, hardcoding it will not
Also - apologies! I just realized that my answer was the same as yours. Sorry. I wasn't trying to steal your glory. I just wasn't paying enough attention 😵
Hi. It's pretty straightforward. This article may be of use: https://community.safe.com/s/article/converting-time-and-date-fields-to-local-timezones
Basically there isn't a transformer, but you use the TimeZoneSet function.
So in an attributeManager you create a new attribute (called zoned for example) with the function:
@TimeZoneSet(@Value(OriginalDateTime),utc)
That creates a new attribute with the UTC timezone attached (if the timezone is already attached, you could leave out that step)
Then a second new attribute (called local for example) with the function:
@TimeZoneSet(@Value(zoned),local)
That creates a new attribute with the local time, such as this:
There is one thing to consider: the "local" part of the second function, means use the local timezone of the computer being used. If you were using an Amazon AWS machine - for example - then its local timezone might be different. If you were worried about that, you could replace "local" with your required time zone (eg +01:00).
However... if you did hard-code the offset, it might be wrong, because sometimes it will be +1 (standard time) and other times +2 (daylight savings). Using "local" might solve that problem. But I'm going to check with our developers, because I'm not sure if that's true.
So I will find out and get back to you. But in the meantime the above functions and the tutorial I pointed to will give you a good starting point.
As far as I know,
Yep, that's what I did (I used "local" since I already had the time in UTC).
Thank you for the article !
The local does not relate to current time, but the time setting of your machine.
The formula should return the following if your machine is set to Paris time
e.g. if the attribute date has a value of 20200429120000 (2020-04-29 12:00:00), this formula will return
20200429120000+02:00 (plus 2 as during summertime
if the attribute date has a value of 202003428120000 (2020-03-28 12:00:00), it will return
20200328120000+01:00 (plus 1 as before daylight savings started)
DateTimeConverter is probably a better way to convert to FME time than with substrings, or @DateTimeParse in the AttributeManager
@DateTimeParse(@Value(date),%d-%m-%Y %H:%M:%S)
Local will allow for daylight savings, hardcoding it will not
Doesn't appear to like the hour between 1 and 2am on the 25th October 2020...
Local will allow for daylight savings, hardcoding it will not
So our developers tell me that we use a big database that is also used by many systems and OSes. I don't know about the 25th October one. We (North America) don't change until next weekend, but I'd be surprised if that caused an issue - unless you were on a virtual machine in this area or using a timezone from over here.
Certainly! You can automatically convert UTC datetimes to Paris local time using programming libraries that handle timezone conversions. Most modern programming languages have libraries to manage this task without manual intervention. Here's an example in Python:
from datetime import datetime
import pytz
utc_time = datetime.strptime('2020-04-29 12:00:00', '%Y-%m-%d %H:%M:%S')
utc_time = pytz.utc.localize(utc_time)
paris_tz = pytz.timezone('Europe/Paris')
local_time = utc_time.astimezone(paris_tz)
print(local_time) # Output: 2020-04-29 14:00:00+02:00
This code snippet automatically handles the Daylight Saving Time changes for Paris, so you don't have to manually apply the "+01:00:00 winter" and "+02:00:00 in summer" rules. The
pytz
library, in particular, is aware of these time changes. Similar libraries exist for other languages as well.
