Set timezone on Meteor server

help
1

I have been playing with NodeChef and Galaxy.
Loving the hosted options, ease of use kicks ass compared with managing my own DO droplets.
The only issue I have is that I want the server to think its timezone is Australian.

Is there a way I can set the meteor server to have a timezone set globally?

2

You can set the ā€œTZā€ environment variable to whatever time zone and your app will see that reported from the OS

Setting environment variable is through settings.json on galaxy.

2 Likes
3

If its that simple thats awesomeā€¦ I will give it a shot.
So for NodeChef I need this:

{
  "METEOR_SETTINGS": {
    "TZ": "Australia/Sydney"
  }
}

and Galaxy this:

"galaxy.meteor.com": {
  "env": {
    "TZ": "Australia/Sydney", 
  }
}
3 Likes
4

Yep! But for what its worth, Iā€™d suggest making your app time zone agnostic bu relying on utc at all times and converting to/from utc as date data gets in/out

momentjs and momenttz combination is a great utility for this

3 Likes
5

Yeah normally I would agree, but the app I am working on pulls data from the local stock exchange.
I need it to follow the local timezone here as it needs to follow the trading day.

6

Just deployed and it looks like it worked perfectly!!

Thanks :slight_smile:

1 Like
7

Iā€™m glad it worked out for you :slight_smile:

Would you like to discuss UTC based approaches to tapping onto that data?

1 Like
8

I really only needed the Timezone thing because I use SyncedCron and only want it to run while the market is open.

I know I could use UTC time, but I donā€™t know if that would take into account DST, and itā€™s nice and easy for me with this:

parser.recur().every(10).minute().after('10:15').time().before('16:30').time().except().onWeekend();

UTC is a bit frustrating because it adds some complexity where it really isnā€™t needed.

However, to be honest I havenā€™t really tried it, but I am guessing it would make running queries a bit more difficultā€¦
I canā€™t just say get me all trades from March, because I mean March in Sydney time.
Mongo will get me all UTC March trades. So I could be out by a whole day and miss some trades and falsely include othersā€¦ right?

9

Hm, well, I know UTC conversion is an overhead compared to an all-local approach, and thatā€™s perfectly fine by the way, as long as you know your app will always be local and all of your users will always deal with local time.

That being said, it is not actually that hard because moment-tz is really clever enough to abstract away all the details, including DST data. (PS: you are lucky you donā€™t live in Turkey. Out government as of last 14 years sporadically decides changing DST switching dates, abandon it altogether and then readapt it just trying to make sure if we ever send a rover to mars, it does get lost :wink: ) (PPS: I know thatā€™s a different problem but just thought it would be cool to demonstrate how working with ā€œinterationally-absoluteā€ data can be a life-saver at times)

Furthermore, synced-cron also does have a utc option for you to decide if you want to work with local time or utc.

In the mongo querying case, you could store the date/time information at UTC and then query them using the UTC equivalent of your local query-bounds.

1 Like
10

Thanks for the detailed post!
Youā€™re points are all really solid, I donā€™t think UTC is as big of a deal as I originally thought.
Iā€™m more thinking now that I overcomplicated what I was trying to do.

Here is another question for you, what do you think about this idea I also had.
This is different to setting the servers TZ to Australiaā€¦

I am storing the date of stock trades. The app doesnā€™t need to store the actual time (hh:mm:ss) or the timezone ā€“ all I need is year, month, day.

How about rather than storing ā€˜Dateā€™ I just store those three attributes?
It would make it much simpler, I could easily evaluate and query trades for each year or each month. Sorting is simple too.

1 Like
11

Yeah it is a fairly common approach but with an inherent problem where you want to sort or span durations that spread across months/years, becides you are then no longer able to leverage the native date type of the database with which you can do fast comparisons, sorting, calculations, aggregations etc

But as I said, depending on the level of complexity with your specific requirements, that may be a perfectly viable approach.

1 Like
12

Yeah thatā€™s a good point, right now I canā€™t think of any reasons to need complex queries on the dates. The trade info is stored just to build the value of portfolios, the trades are only ever visible when you edit the portfolio and I suspect I will want to be able to filter/sort them in that view.

Thanks again for letting me bounce the ideas around :slight_smile:

1 Like
13

@serkandurusoy im in a similar position to cstrat, im polling a local market api using the date the server generates and saving the data in mongo but want to be able to run the app anywhere. Do you have time to chat about ways to write timezone agnostic code?

14

@lucaed if you are offering me a job, please PM me, otherwise, please ask your question here, either I or any one of the friendly community members will be doing their best to keep the conversation going and both your question and its answer will have been recorded in internet history for anyone interested :slight_smile:

4 Likes
15

Not sure about your particular example.

Mine is all to do with stock trading, so I need to store the end of day value for shares.
So for me to store the date, rather than use a formal date object, I just store:

date: {
  d: 20,
  m: 12,
  y: 2010
}

This allows me to run queries on particular dates and date ranges pretty easily.