Is there a special place for the time zone setting...
# lucee
p
Is there a special place for the time zone setting in Lucee? Using the web admin I’ve set it to “America/New_York”, but my app was still showing GMT time. I’m using
setTimeZone("EDT")
in my app, and that’s fine for outputting time, but the log files from LogBox are all timestamped with GMT times. I’m not sure if I have a problem with a Lucee/app config, the JVM timezone or something. The OS time setting is correct and verified.
t
Your app and LogBox probably have their own timezone setting? It should be something likes below in Application.cfc
Copy code
this.timezone = "Australia/Sydney";
e
in tomcat, or your java opts env, you can add -Duser.timezone=America/New_York edit, restart your instance
d
While I know it's not the question that was asked, I'd recommend always using GMT for timestamps. While using your local time may initially make it easier to digest the information, there's much less ambiquity with using GMT. With a timezone like EDT, there's always going to be an issue during DLS falling back that will lead to ambiquity. GMT has no DLS changes, so you always know exactly when something happened.
💯 1
❤️ 1
j
piggybacking on what @dswitzer said, it can be really hard to get yourself out of a hole that you dig for yourself when you set a server to a local time zone. i've wanted to get out of that hole on my application for 10 years now (because back in the day, our data center folks put the app/server that i inherited on chicago time), but it's really complicated to do so, which is why progress has stalled.
d
That said I use local timezone on lucee and server and GMT to store dates so I dont always have to convert now() as 99% of the time my timestamps automate on record creation and i have updated row which triggers to autoupdate on row change via db. (zero trust in another dimension (compliance) #lol) My c2c.
d
I like sticking with GMT across the board, because then there's never any confusion about what timezone a timestamp should be in. I've just find this to be the best overall strategy for me and our team. It's helpful when I'm debugging because I know timestamps in my database, logs, etc should all match. Even if you never think you're going to be dealing with times outside of your own timezone, I've just found it's better to use GMT. It handles the situations already discussed, but if your application needs grow and you find yourself needing to deal with multiple timezones, switching afterwards is very painful. While abstracting for future "possibilities" isn't always right, I see GMT as just a "best practice". It may seem unnecessary, but when you start projects that way it's very easy to handle. Just my 2 cents...
d
i store dates in gmt, but set server to local time, most of our datetime stamps are generated by db anyway as defaults... Also as we are in Australia all our locale info is defaulted to en_au, dates, times, currency, language, etc... we have a complete locale package that I wrote about 10 years ago that handles all that.